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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
