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

[Duncan Murdoch]

On 8/30/2006 6:33 AM, Prof Brian Ripley wrote:
> On Wed, 30 Aug 2006, Martin Becker wrote:
> 
>> 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.
> 
> Actually, Rprof does time elapsed time on Windows.  Calling gc() first is 
> important, and part of what system.time() does.
> 
>>> 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.
> 
> Isn't that usually done by adding rnorm()s and not runif()s?
> 
> There are much better algorithms for simulating Brownian motion
> barrier-crossing statistics to high accuracy.  It's not my field, but one 
> idea is to use scaled Brownian bridge to infill time when the process is 
> near a boundary.

McLeish published algorithms to simulate these directly in a recent 
issue of CJS.  I don't have the reference handy, but I think it's 2004 
or 2005.

Duncan Murdoch

> 
> Sometimes the R helpers spend a long time answering the wrong question, 
> which is why it always helps to give the real one.
> 
>>> 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
>>
>>
>