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
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?
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost