1

Topic: MSVC std:: unordered_map bucket_count ()

Noted that in MSVC to implementation std:: unordered_map <int, int>:: bucket_count () always returns a twain level. Whereas other tested implementations (STL from online of compilers gcc and clang, and also boost) return a prime number. Colleagues how think, such behavior MSVC is, more likely, it is good (bit operation instead of division into a prime number) or it is bad (collisions with cut to an index of union a hash) are more probable?

2

Re: MSVC std:: unordered_map bucket_count ()

Hello, Alexander G, you wrote: AG> Colleagues how think, such behavior MSVC is, more likely, it is good (bit operation instead of division into a prime number) or it is bad (collisions with cut to an index of union a hash) are more probable? It is possible to esteem here: http://stackoverflow.com/questions/1145 … er-modulus it is short - if a hash function good, baskets are unimportant how many (that is the twain level it is optimal for on the unit quickly function "not so" better on top  is considered the simple unit) if a hash

3

Re: MSVC std:: unordered_map bucket_count ()

Hello, Alexander G, you wrote: AG> and also boost in  some policies how to inflate kol-in baskets see boost\unordered\detail\buckets.hpp

4

Re: MSVC std:: unordered_map bucket_count ()

Hello, uzhas, you wrote: U> in  some policies how to inflate kol-in baskets are a pity, in the interface is not stretched, it is necessary to trust the autopilot. But there the interesting comment://While the mix policy is generally faster, the prime policy is a lot//faster when a large number consecutive integers are used, because//there are no collisions. Since that is probably quite common, use//prime policy for integeral types. But not the smaller ones, as they//do not have enough unique values for this to be an issue. Unfortunately that they name mix policy, is activated only on 64-bit size_t, accordingly, on 32-bit assembly there always will be prime policy

5

Re: MSVC std:: unordered_map bucket_count ()

Hello, uzhas, you wrote: U> it is possible to esteem here: http://stackoverflow.com/questions/1145 … er-modulus U> it is short - if a hash function good, baskets are unimportant how many (that is the twain level is optimal for on the unit) U> if a hash function "not so" better on top  simple unit As though still to learn, whether good a hash function quickly is considered. We admit, I use integer numbers as keys, lines are more rare, is even more rare -  and pointers. For all it there is standard a hash function. On the one hand, it is logical to assume that standard implementation a table hash is calculated for operation with standard a hash function on the normal data. On the other hand, on a rake of implementations in VS 2012 that in boost worked well, already came: [VC2012] the problem with std:: this_thread:: get_id () VS 2012 call_once is broken Here and doubts, can and to take better in this case old kind boost

6

Re: MSVC std:: unordered_map bucket_count ()