Re: randn benchmarks

[Paul Kienzle]

Comparing apples to apples (randmt to rand instead
of randn), I find that octave-forge's rand is faster on
both IRIX and Linux.  I can squeeze another 25% out
of it by directly accessing the array values.  I will need
to do this anyway for N-d array support.  I will post this
code in a bit (it is on another machine which just stopped
responding).

I would also like to switch to using the mainline
code for MT (mt19937ar-cok.c) and I've made the
appropriate changes to allow this.  However this
will generate a different sequence from the same
seed, so I would rather not make this change until
we are ready to move to a randn based on ziggurat.

Still have no word on license for ziggurat...

Paul Kienzle
address@hidden


On Jan 23, 2004, at 5:33 PM, Dmitri A. Sergatskov wrote:

> Dirk and Paul,
>
> While we at it. Could someone explain it to me why Dirk's randmt is  
> few times
> faster than the randn from octave-forge?
>
>
> octave:2> tic ; randmt(1000); toc
> ans = 0.055763
> octave:3> tic ; randmt(3000); toc
> ans = 0.77237
> octave:4> tic ; randmt(10000); toc
> ans = 26.469
> octave:5> tic ; randn(1000); toc
> ans = 0.31140
> octave:6> tic ; randn(3000); toc
> ans = 2.7659
> octave:7> tic ; randn(10000); toc
> ans = 30.786
> ((( It does seem that times converge for very large arrays...)))
> octave:8> which randn
> randn is the dynamically-linked function from the file
> /usr/local/libexec/octave/2.1.50/site/oct/i686-pc-linux-gnu/octave- 
> forge/randn.oct
>
>
> Sincerely,
>
> Dmitri.