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

Subject: [boost] [xint] Boost.Move vs Copy-on-Write timings, remeasured
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-05-04 10:51:33

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks to a bug that I was blind to, and that Jeffrey Hellrung gently
pointed out (for which I give him public thanks), the earlier timings
weren't accurate. I've corrected the problem and remeasured the times.

You can find the earlier timings, along with the details of the testing,
here: <http://permalink.gmane.org/gmane.comp.lib.boost.devel/203539>.

Here are the updated timings (for release builds only, I didn't see a
point in doing debug builds this time):

Baseline:      8.6, 8.8, 8.8  (8.73)
GCC move:      8.6, 8.6, 8.8  (8.67)
Emulated move: 8.8, 8.5, 8.6  (8.63)
Copy-on-write: 6.5, 6.7, 6.9  (6.70)

Comparing to the originals, it looks like the change benefited all four,
but I guarantee that it couldn't have affected the copy-on-write score.
The only way I can explain the overall reduction is that my (virtual)
development machine was running slower in the old tests.

The change in relative scores is more interesting. The baseline, GCC
move, and emulated move scores are now within 1% of each other, strongly
suggesting that the compiler's Return Value Optimization is making the
inclusion of Boost.Move nearly irrelevant. Emulated move semantics still
beat out the compiler-supplied ones, but the difference is so small that
that could well be within the margin of error.

What is surprising and somewhat baffling to me is that even though the
copy-on-write code wasn't affected by the change, that version is
*still* better, and by an even (slightly) larger percentage than before
(23.2%, as opposed to 21.7% in the previous test). I can only come up
with two possible explanations for that: either there's some other piece
of code in there that's preventing move semantics from working to their
full potential, or copy-on-write is benefiting something other than
return values, and by a ridiculously large amount. In either case, I
don't know what could be responsible, but I'll keep looking for it.

The updated code is now in the sandbox, for those who might want to test
it themselves.
- -- 
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/

iEYEARECAAYFAkvgNHEACgkQp9x9jeZ9/wRAOACeMf9Lvu2Zn/uduwRAVYIH11o9
swgAoKsmap30FR4MywZ1uy+ON2+gjfy7
=VoRk
-----END PGP SIGNATURE-----