From octave-maintainers-request at bevo dot che dot wisc dot edu Sat Jan 24 14:33:35 2004
Subject: Re: randn benchmarks
From: Paul Kienzle <pkienzle at users dot sourceforge dot net>
To: "Dmitri A. Sergatskov" <dmitri at unm dot edu>
Cc: David Bateman <David dot Bateman at motorola dot com>,    Paul Kienzle <pkienzle@users.sourceforge.net>,    Dirk Eddelbuettel <edd@debian.org>, octave-maintainers@bevo.che.wisc.edu
Date: Sat, 24 Jan 2004 15:32:06 -0500

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
pkienzle at users dot sf dot net


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.
>