-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've done some further testing, eliminating the Boost.Thread locking on the random number generator as a factor, as promised earlier today. Here are the raw timings: (Debug build) Baseline: 29.4, 36.0, 32.8 (32.73) GCC move: 32.0, 35.3, 31.2 (32.83) Emulated Move: 28.4, 33.8, 28.4 (30.20) Copy-on-write: 27.3, 25.0, 26.9 (26.40) (Release build) Baseline: 10.5, 12.5, 10.6 (11.20) GCC move: 11.3, 13.0, 10.4 (11.57) Emulated move: 10.0, 10.8, 9.7 (10.17) Copy-on-write: 8.5, 8.4, 9.4 ( 8.77) Times are measured in seconds, using two sets of ten 2048-bit integers. The tests consisted of adding each of those pairs of numbers together 10,000 times, multiplying them 10,000 times, and doing a "mulmod" operation on them (with a third randomly-generated 2048-bit modulus argument) 1,000 times. Each test was run three times, under as close to identical situations as I could manage, with the raw results (rounded to the nearest tenth of a second) in the first three columns; the fourth column is the average of the three. The compiler used was GCC 4.4.3, under Ubuntu Linux 10.04. The release build used -O2 optimization; the debug build used none. Otherwise, the settings were left at their defaults, except where noted below. The baseline configuration had neither copy-on-write nor any kind of move semantics enabled. The "emulated move" rows used the baseline configuration plus Boost.Move in C++03 emulation mode, with no copy-on-write; the "GCC move" rows indicate the exact same configuration, except that I used "-std=c++0x" as well (so presumably Boost.Move would switch to compiler-supplied move semantics). The copy-on-write rows used the baseline configuration, but enabled my copy-on-write system. Using the calculation... (baseline_time - time) / baseline_time ... copy-on-write provided a 19.3% and 21.7% speed increase over the baseline settings. Boost.Move emulation provided 7.7% and 9.2%. GCC-provided move semantics were, surprisingly, the worst performers, coming in at 0.3% and 3.3% *worse* than the baseline performance. I'm assuming that that code hasn't been optimized yet, and that it will eventually be a lot faster. Conclusions: * The copy-on-write system is faster than Boost.Move emulation by a respectable amount, and an even greater one than my earlier tests indicated. * The non-thread-safe version is *not* twice the speed of the thread-safe one, as I erroneously indicated before. Much of the difference must have come from the random number locking. It's still markedly faster, as it uses copy-on-write and the thread-safe version can only use Boost.Move, but only by about 12%. Am I missing any statistics? Does anyone want the test code to reproduce this and look for errors in my test setup? It's only a small modification from the code in the sandbox and vault, plus the test function. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvd5ZwACgkQp9x9jeZ9/wTnnQCfYt1MrUNFGnYKNJImYKuuryDf HfYAoIrXeBgsT25cCwI/oiIAShSyvyh0 =nZxq -----END PGP SIGNATURE-----