Re: [boost] [xint] Third release is ready, requesting preliminary review

Subject: Re: [boost] [xint] Third release is ready, requesting preliminary review
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-05-02 13:52:39

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

On 05/02/2010 01:13 PM, vicente.botet wrote:

> Are you saying that given the following functions
> 
> xint::integer cow();
> boost::rv<xint::integer> m();
> xint::integer i;
> 
> i = cow() is faster than i = m() on a single thread environement?

That's exactly what I'm saying. Which makes some sense, when you think
about it... if the compiler doesn't optimize it perfectly, then it's
spending CPU cycles to create the the boost::rv type, only to assign it
to another integer and destroy it again. Copy-on-write doesn't need to
do any of that.

> If yet, what is the ratio you have measured?

It looks like I didn't save the file with the results, but they were
something like copy-on-write being 0.3 seconds faster than neither, and
move being about 0.15 seconds faster. The test took roughly three
seconds at its fastest, if I recall correctly, which would make
copy-on-write about 5% faster than move semantics if I've got my sums
correct.

(The ratio could vary depending on the size of the numbers used though.
Larger numbers *should* produce larger savings, since copying them would
be more expensive. Though the library would also spend more time within
the functions processing each number, so I'm not certain about that.)

I'll have to recreate that test code anyway, in order to see how the
random number locking affected the speed, so I'll have more detailed
results to post later today.
- -- 
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/

iEYEARECAAYFAkvdu+YACgkQp9x9jeZ9/wRiPACg73Mc9wp3Ldnc8cIuwURpFevd
mZ8AniHgHr1WH1PXYtb1dL0XZK6j1xoh
=uioo
-----END PGP SIGNATURE-----