Your subject line is seriously misleading: this is not `in R' but rather in the pre-compiled binary of R on one OS (Windows) against one particular runtime (which was actually changed long before R 1.7.1).
You could not do this by an `R package': that cannot change the runtime code in use. You (or someone else) could build R against an alternative runtime library system, but it might be easier to use a better OS. I have yet to see any real statistics application in which this made any noticeable difference. With modern processors one is talking about 10x faster than a few milliseconds unless the datasets are going to take many seconds even to load into R. If you have such an application (a real example where ^ takes more than say 20% of the total time of the statistical analysis, and the total time is minutes) please share it. On Tue, 18 Nov 2003, Philippe Grosjean wrote: > >Did the MingGW folks consider the simple solution of simply rounding the > >return result when the inputs are integers? > > >-G > > It seems this is the problem, rounding... because some fast algorithms > return wrong integers, but acceptable reals (given the precision). Also, it > seems that most of the decrease in performance is due to checking of > overflow and so on. Recent Intel processors (and certainly many others) > provide fast instructions for some usual mathematical functions, but they > are not used in MingW (any more), because they do not meet standards for > precision and error checking (note that I am not a specialist at all, that > is my understanding after searching on the net about it). > > So, as I understand, it is possible to compute much much faster, but with > less "security" than in the current MingW version. However, people at MingW > priviledge precise and secure calculation at the expense of performance (to > meet standards). > > There are certainly a few occasions in statistics (where the highest > precision in calculation often does not matter) when faster, but less > precise algorithms would be better... That is why I dream about a "fastmath" > R package to propose a faster alternative to ^, exp(), cos(),... When there > a factor ten in speed increase for ^, this is probably worthwhile. However, > this can only be a dream for me, since I cannot do it myself. I wonder if > someone else would be interested. In this case, http://www.willus.com/mingw/ > could be probably a starting point. > > Best, > > Philippe Grosjean > > > -----Original Message----- > > From: Philippe Grosjean [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, November 12, 2003 10:50 AM > > To: [EMAIL PROTECTED] > > Subject: [Rd] Power (^) 10x slower in R since version 1.7.1... What > > next? > > > > > > OK, I have made a little search about this "problem" that > > apparently occurs > > only on Windows platform... (but I am sure most of you are > > already aware of > > it): the slow down is due to the adoption of a different > > algorithm for pow > > in mingw 3.x. This is motivated by some other changes in > > mingw. Here is a > > quote of Danny Smith that did this change: > > > > >When mingw changed default FPU settings from 53-bit mantissa > > >to 64 bit mantisa, the dll-provided pow function no longer > > >returned integral values when both operands were integral. > > Now, I don't > > >think that is a requiremnet of the standard but every other pow > > >implementation I looked at did that. So I changed to a well-tested > > >pow function (from the Cepehes math library) that did. As > > you found out > > >it is expensive. > > > > >I have written another pow function that use exp2 and log2 library > > functions > > >rather than the polynomial expansion used by Cephes package. > > It seems to > > be > > >accurarte enough (except when the result of pow is near 1.0 (eg, > > pow(1.00001, 0.99999)) > > >and is as fast as the msvcrt.dll version. I still need to > > tweak for cass > > >near range boundaries. > > > > >The other alternative is to write a wrapper for the wrapper > > for the dll > > pow, > > >to fix up the special cases when both args are integral. > > That doesn't add > > to > > >much overhead. > > > > >Danny > > > > Since pow is much, much slower in mingw 3.x than in mingw > > 2.x, other people > > started to search for a solution. I found this interesting enough: > > http://www.willus.com/mingw/ (look at "Some Fast Math > > Functions" at the end > > of the page). > > > > Thus here, there are two possibilities: to match the > > standards and provide > > full-proof math functions, like it is done in current mingw (and in R, > > consequently)... but sacrificing speed. Or, to rely to online > > assembler that > > uses Pentium or Athlon fast calculation potentials (but with > > less checking > > of errors) like Willus proposes. > > > > I think at this point, it should be the user's choice. So, R > > should propose > > both and should allow to switch from one to the other easily. Any > > suggestion? (one idea: make a fastmath package that would > > provide faster, > > but less error-proof ^, exp(), cos(), sin(),... functions). > > Unfortunately, I > > am not fluent enough in C and assembler to do it myself. > > > > Best, > > > > Philippe Grosjean > > > > ...........]<(({°<...............<°}))><...................... > > ......... > > ) ) ) ) ) > > ( ( ( ( ( Dr. Philippe Grosjean > > ) ) ) ) ) > > ( ( ( ( ( LOV, UMR 7093 > > ) ) ) ) ) Station Zoologique > > ( ( ( ( ( Observatoire Océanologique > > ) ) ) ) ) BP 28 > > ( ( ( ( ( 06234 Villefranche sur mer cedex > > ) ) ) ) ) France > > ( ( ( ( ( > > ) ) ) ) ) tel: +33.4.93.76.38.16, fax: +33.4.93.76.38.34 > > ( ( ( ( ( > > ) ) ) ) ) e-mail: [EMAIL PROTECTED] > > ( ( ( ( ( SciViews project coordinator (http://www.sciviews.org) > > ) ) ) ) ) > > .............................................................. > > ......... > > > > ______________________________________________ > > [EMAIL PROTECTED] mailing list > > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel > > > > > LEGAL NOTICE\ Unless expressly stated otherwise, this messag...{{dropped}} > > ______________________________________________ > [EMAIL PROTECTED] mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel > > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595 ______________________________________________ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
