Subject: Re: [boost] unordered_map 32bit VS 64bit
From: Grund, Holger (ISGT) (Holger.Grund_at_[hidden])
Date: 2012-01-25 14:05:01
> I'm porting a project from Linux 32bit to Linux 64bit. While doing so I
> notice that I have a dramatic performance degradation with
> My platform is Ubuntu 10.4.3 64bit running on Intel Xeon X3220 but, I
> tested similar program on WindowsXP SP2 64bit which running on Intel i5
> I get the same degradation. My boost version is 1_46_1.
> I use the following program in order to test unordered_map - Hop I
> make any copy mistakes :-).
> #include <stdio.h>
> #include <sys/time.h>
> #include <boost/unordered_map.hpp>
> int main(int argc, char *argv)
> struct timeval tv_before, tv_after;
> boost::unordered_map<boost::int_32_t, boost::int32_t> boost_map;
> boost_map = 2;
> boost_map = 4;
> gettimeofday(&tv_before, NULL);
> for(int i = ; i < 100000; i++)
> gettimeofday(&tv_after, NULL);
> printf("Boost time is %f \n",
> (double)(((tv_after.tv_sec - tv_before.tv_sec) * 1000000 +
> (double)(tv_after.tv_usec - tv_before.tv_usec)) / 100000));
> return 0;
> I use the following compile commands:
> 64bit - g++ -O3 perf_test -o perf_test_64bit
> 32bit - g++ -m32 -O3 perf_test -o perf_test_32bit
> When I run the 32bit program I get 0.5 sec
> When I run the 64bit program I get 1.54 sec
> Any ideas ???
My guess would be that there is 64-bit division for transforming the hash to a bucket index, which is killing perf (though one would wonder why there are no peeps for an instructions like MOD(1,x) in the codegen).
I guess, you could try out by changing the bucket count and hash code to a uint32_t in the 64-bit build.
Most compilers will transform a div by constant to a mul. Maybe some toolchains would replace a div by bucketcount with a MUL when doing value-range PGO and numbers are reasonably stable (i.e. there is some geometric growth with a factor of ~2 or so, so that there's only a handful of divisors).
NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk