On 23/07/10 23:20, Paul Eggert wrote: >>> 3. We could get about 2X CPU performance on 64-bit machines by using >>> ISAAC64 instead of ISAAC. >>> >> These are all welcome changes, and the patch for (1) looks fine. > > OK, here's the change for (3), which I just pushed. I verified that > it improved performance of random-number generation by 2x on my > 64-bit host (RHEL 5 host with a Xeon E5620; the benchmark performance > improvement was actually a tiny bit better than 2x speedup). On this > platform isaac_refill now generates pseudorandom data at around 2.5 GB/s, > which is quite a bit faster than /dev/urandom's 7.5 MB/s > (as measured with dd).
Very nice. > On 32-bit hosts the code behaves as before, though I expect it runs a > bit faster than before (I haven't checked this). Same performance on 32 bit here: $ git pull origin $ gcc -march=pentium-m -O2 -I lib gl/tests/test-rand-isaac.c lib/libcoreutils.a $ time ./a.out 10000000 real 0m13.093s $ (cd lib && make) CC randread.o CC rand-isaac.o AR libcoreutils.a $gcc -march=pentium-m -O2 -I lib gl/tests/test-rand-isaac.c lib/libcoreutils.a $ time ./a.out 10000000 real 0m13.115s Note I needed to comment out the ASSERT check when linking with the old rand-isaac. Is that a bug in the old implementation or just a change? > > Perhaps this stuff should be moved to gnulib? I can't recall if there > was any good reason to leave it in coreutils. > Inertia more than anything I think. > +++ b/gl/tests/test-rand-isaac.c > + > +/* FIXME: once/if in gnulib, use #include "macros.h" in place of this */ > +#define ASSERT(expr) \ Hmm, I just used macros.h in test-mbsalign.c which seems ok I'm marking this rand update series as done. cheers, Pádraig.
