[boost] [xint] Boost.Move vs Copy-on-Write timings

Subject: [boost] [xint] Boost.Move vs Copy-on-Write timings
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-05-02 16:50:40

-----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-----