R devel - Nov 2003 - 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: phgrosjean@sciviews.org
( ( ( ( (       SciViews project coordinator (http://www.sciviews.org)
 ) ) ) ) )
.......................................................................

>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:phgrosjean@sciviews.org]
> Sent: Wednesday, November 12, 2003 10:50 AM
> To: r-devel@stat.math.ethz.ch
> 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: phgrosjean@sciviews.org
> ( ( ( ( (       SciViews project coordinator (http://www.sciviews.org)
>  ) ) ) ) )
> ..............................................................
> .........
>
> ______________________________________________
> R-devel@stat.math.ethz.ch mailing list
> https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
>

LEGAL NOTICE\ Unless expressly stated otherwise, this messag...{{dropped}}