Rigorous testing of Visual Studio C ++ hash_map-reprinted

After the last test, a netizen mm304321141 (Minger) questioned the test data on the message. Thank you for your correction. I do not know that the hash_compase of the default dinkumware STL hash_map in Visual Studio C ++ has two parameters bucket_size and min_buckets. In my own implementation, the class is inherited from stdext: hash_compare, the two parameters were ignored, and the default template parameters were used during the last test.

The benchmark testers are most afraid of being less rigorous. Although my private test environment is hard to serve the public, this test should be as serious as possible.

Test Environment: Private machine, genuine, 1.6 GB dual-core, 2 GB memory

Tested Compiler: msvc 2005 (2003 used last time)

TestCodeAs follows:

# Include <stdio. h>

# Include <conio. h>

 

# Include <iostream>

# Include <map>

# Include

# Include <algorithm>

 

# Include <ACE/OS. h>

# Include <ACE/time_value.h>

 

Const size_t test_number = 200000;

Const size_t init_buckets_number = 262144;

 

Class test_hash_compare

{

 

Public:

// Note that I have redefined these two parameters. [note]

Static const size_t bucket_size = 4;

Static const size_t min_buckets = init_buckets_number;

// Static const size_t min_buckets = 8;

Test_hash_compare ()

{

}

Size_t operator () (const size_t & Key) const

{

Return key;

}

 

Bool operator ()(

Const size_t & _ key1,

Const size_t & _ key2

) Const

{

Return (_ key1 <_ key2 )? True: false;

}

};

 

Void test_hash_map ()

{

 

Ace_time_value tvstart (0 );

Ace_time_value tvend (0 );

Ace_time_value tvpasstime (0 );

 

Tvstart = ace_ OS: gettimeofday ();

 

// This macro is available only after stlport is used

# If defined _ stlport_version

STD: hash_map <size_t, int> int_hash_map;

// Pay attention to this line of code. The default STL of vs. Net does not have this function, and the stlport implementation has this function.

Int_hash_map.resize (init_buckets_number );

# Else

Stdext: hash_map <size_t, Int, test_hash_compare> int_hash_map;

# Endif //

 

// Test 0.2 million times

// Insert a group of data in sequence

For (size_t I = 0; I <test_number; ++ I)

{

Int_hash_map [I] = 0;

}

 

// Query 0.4 million times, half of which can be queried, and half cannot.

For (size_t I = 0; I <2 * test_number; ++ I)

{

Int_hash_map.find (I );

}

 

// Get the time difference in milliseconds

 

Tvend = ace_ OS: gettimeofday ();

Tvpasstime = tvend-tvstart;

 

STD: cout <"test_hash_map gettimeofday:" <tvpasstime. msec () <"<STD: Endl;

};

 

 

Int main (INT argc, char * argv [])

{

For (Int J = 0; j <5; ++ J)

{

Test_hash_map ();

}

_ Getch ();

Return 0;

}

The last time I used the debug version, on the one hand, I thought it was troublesome. On the other hand, I felt that my code was simple and worried that some optimizations would lead to unfair results. This time I used the release version for comparison. The test results are as follows:

Table 1 tests hash_map in several environments

Test Method
The hash_map in stlport version does not use the resize function.

(MS)
Use the resize function before testing hash_map of stlport version.

(MS)
Microsoft msvc2005 uses the default hash_map of STL and uses the custom hash_compare function.
Microsoft msvc2005 uses the default hash_map of STL and uses the default hash_compare function.
 
 

 

 

[Note] according to my definition of bucket_size and min_buckets in msdn, I also made some adjustments to bucket_size and did not find any special optimization space, if the adjustment is greater, the speed of reduction will be affected.

[Note] Why is it faster for the first time? I am a bit confused. I thought it was infected with data first, but I found that the first time it was indeed faster, and I was a bit skeptical that it was caused by a page exchange error.

[Note] When I used the debug version for testing, I found that each function execution event was very long, but I waited for the event unexpectedly for a long time and read the test code a little, it is estimated that the problem is caused by memory check of the debug version of msvc.

 

The results of the test, msvc results are not more competitive, just think about it, my test is indeed more inclined to stlport, its small object distributor in the middle of my test may take advantage. Of course, this is also a good place for stlport (sgi stl) design.

Finally, I am still helpless about msvc implementation, or it is not high. Even if bucket_size and min_buckets are optimized in the hash_compare, the speed can be improved. However, to perform initialization in this way, many developers need to re-implement hash_compare to achieve optimal performance.

It's still the old suggestion. If possible, you can consider using the stlport implementation. Of course, you may have to pay a lot of costs (almost re-compile all the libraries)

Finally, I would like to thank mm304321141 (tomorrow!

 

[The author of this article is fullsail (Yandu hantan). In the spirit of freedom, you can repeat this document in a non-profit situation. For details, refer to the blog link: http://blog.csdn.net/fullsail .]

 

This article is from the csdn blog. For more information, see http://blog.csdn.net/fullsail/archive/2009/12/21/5045355.aspx