Boost logo

Boost :

Subject: Re: [boost] [random] new threefry random engine
From: Thijs (M.A.) van den Berg (thijs_at_[hidden])
Date: 2014-04-20 12:57:35


On Apr 20, 2014, at 6:30 PM, Beman Dawes <bdawes_at_[hidden]> wrote:

> On Sun, Apr 20, 2014 at 7:17 AM, Thijs van den Berg <thijs_at_[hidden]> wrote:
>
>> ...
>> // loop version
>> threefry4x64_08_64: 10.2318 nsec/loop = 19.13350 CPU cycles
>> threefry4x64_13_64: 14.3048 nsec/loop = 26.75000 CPU cycles
>> threefry4x64_20_64: 22.6186 nsec/loop = 42.29680 CPU cycles
>> threefry4x64_99_64: 100.0110 nsec/loop = 187.02200 CPU cycles
>>
>> // 40x manual unrolled version
>> threefry4x64_08_64: 3.7386 nsec/loop = 6.99118 CPU cycles
>> threefry4x64_13_64: 5.1223 nsec/loop = 9.57870 CPU cycles
>> threefry4x64_20_64: 7.3078 nsec/loop = 13.66560 CPU cycles
>> threefry4x64_99_64: 29.3599 nsec/loop = 54.90300 CPU cycles
>>
>> You may want to ask others to run the tests with various CPU's and
> compilers. Making optimization decisions based on a single platform can be
> quite misleading.
>
> Remember Knuth's famous quote: "*premature optimization is the root of all
> evil*":-)
>
Very true. Most of the times the biggest gain is in math or the algorithm. It would be nice if people could help with testing performance.

I thought a factor 2.5 drop in performance by making it more generic was too big to ignore, it would make the engine less interesting as a new choice and that would be to bad. My goals is to add value and I use this engine myself for MC simulations. I think it's fine now -there is nothing fancy going on-, I think performance is more predicable now, it depends less on the smartness of compilers.

I'm new to this, but it there a pool of compilers testing new versions of boost that could also test performance?

> --Beman
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk