[Rd] Speed of runif() on different Operating Systems

[Martin Becker]

Prof Brian Ripley wrote:
> No one else seems to have responded to this.
>
> Please see `Writing R Extensions' for how to time things in R.
>
>   
Thank you very much for the pointer to system.time(), although I read 
most of 'Writing R Extensions', I must have overlooked this (very 
useful) part. Nevertheless I was aware, that Sys.time() does not measure 
cpu time (that's why I included the information, that measuring time 
with Rprof() yields similar results, I had better included the output of 
Rprof indeed), but I was the only user on both (idle) dual core systems 
and thus expected a high correlation between the differences of 
Sys.time() and the cpu time actually used.
> For things like this, the fine details of how well the compiler keeps the 
> pipelines and cache filled are important, as is the cache size and 
> memory speed.  Using
>
> system.time(for (i in 1:500) ttt <- runif(1000000))
>
> your Linux time looks slow, indeed slower than the only 32-bit Linux box I 
> have left (a 2GHz 512Kb cache Xeon) and 2.5x slower than a 64-bit R on an 
> 2.2GHz Opteron (which is doing a lot of other work and so only giving 
> about 30% of one of its processors to R: the elapsed time was much 
> longer).
>
> The binary distribution of R for Windows is compiled with -O3: for some 
> tasks it makes a lot of difference and this might just be one.
>
>   
Thank you very much for this valuable piece of information, it explains 
a big part of the speed difference: recompiling R on my linux box with 
-O3 significantly increases speed of runif(), now the linux box needs 
less than 40% more time than the WinXP system.
> However, what can you usefully do in R with 5e8 random uniforms in 
> anything like a minute, let alone the aggregate time this list will spend 
> reading your question?  
The standard method for simulating final, minimal and maximal values of 
Brownian Motion relies on a (discrete) n-step random walk approximation, 
where n has to be chosen very large (typically n=100 000) to keep the 
bias induced by the approximation "small enough" for certain 
applications. So if you want to do MC option pricing of e.g. double 
barrier options, 5e8 random uniforms are needed for 5 000 draws of 
final, minimal and maximal value, which is still a quite small number of 
draws in MC applications. I am working on a faster simulation method and 
of course I want to compare the speed of the new and (old) standard 
method, that's why I needed large numbers of random uniforms. I thought 
that the particular application is not of interest for this list, so I 
left it out in my initial submission. I apologise, if my submission was 
off-topic in this mailing list.
> If it matters to you, investigate the code your 
> compiler creates.  (The ATLAS developers report very poor performance on 
> certain Pentiums for certain versions of gcc4.)
>
>   
Thank you again for the useful hints!

Regards,

  Martin Becker