Does the source actually use the default power function from the cmath library?

It seems to me that I heard the default algorithm was actually somewhat
inefficient.

Please correct me if I'm wrong.

Regards,
A.D.B.

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Le 08/08/2015 07:48, Anthony D. Baye a écrit :
> Does the source actually use the default power function from the
> cmath library?
> 

Where ? in the SDL or function in the SDL, or internally ?

In the SDL, yes, it's mapped to whatever the math library provide for
pow().

In function, yes too.

Internally, oh yes!


> It seems to me that I heard the default algorithm was actually
> somewhat inefficient.
> 

All that is rumour so far. You vaguely heard that it would be vaguely ..
.

If you are referring to something like

http://stackoverflow.com/questions/9652549/self-made-pow-c

(second answer, with POW(a,b) = EXP(LOG(a)*b) ) it's a trick that
works only :
1. on float of 32 bits
2. with Ieee-757 representation normalised value

(Remember that such float only provide 6 to 7 significant digits)

That's a non-portable optimisation which does not even handle corner
situation (when the number is denormalized due to the encoded value,
or NaN... ).

BTW, the OP of LOG also assumed that int type is at least 32 bits...
oh the hard delusion on some architectures (this year (2015), I still
have to handle a modern chip (or rather SoC) with int of 16 bits: its
natural size (it can do 64 bits, but it costs more))


> Please correct me if I'm wrong.
> 
> Regards, A.D.B.
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iJwEAQEIAAYFAlXGBy8ACgkQhKAm8mTpkW1XFgP+KZ/ASzfUBzPXFw0gHoXKBixQ
RoSLXuvheJsJRQpTaqi3d5mijMsn32ARnwTIvtyUPy/ehJKQXgdcLOIYNSKcDDgO
E5SwKnJnqAgxuWsWJCz4kKG2TjAkiFtEhuj8DRK5YaUFhIW8lxJyncToJZgjCcMK
6hohRLifjF0NAachrwg=
=mdFT
-----END PGP SIGNATURE-----

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Le 08/08/2015 07:48, Anthony D. Baye a écrit :
> > Does the source actually use the default power function from the
> > cmath library?
> >
>
> Where ? in the SDL or function in the SDL, or internally ?
>
> In the SDL, yes, it's mapped to whatever the math library provide for
> pow().
>
> In function, yes too.
>
> Internally, oh yes!
>
>
> > It seems to me that I heard the default algorithm was actually
> > somewhat inefficient.
> >
>
> All that is rumour so far. You vaguely heard that it would be vaguely ..
> .
No need to get snippy.  I remember having to write a fast exponentiation
function for a class once.  It's been a while.

>
> If you are referring to something like
>
> http://stackoverflow.com/questions/9652549/self-made-pow-c
>
> (second answer, with POW(a,b) = EXP(LOG(a)*b) ) it's a trick that
> works only :
> 1. on float of 32 bits
> 2. with Ieee-757 representation normalised value
>
> (Remember that such float only provide 6 to 7 significant digits)
>
> That's a non-portable optimisation which does not even handle corner
> situation (when the number is denormalized due to the encoded value,
> or NaN... ).
>
> BTW, the OP of LOG also assumed that int type is at least 32 bits...
> oh the hard delusion on some architectures (this year (2015), I still
> have to handle a modern chip (or rather SoC) with int of 16 bits: its
> natural size (it can do 64 bits, but it costs more))
>

So, even using the double versions for pow and exp doesn't necessarily improve
anything?

I'm just asking questions.  I can't learn (much) if I don't ask questions.

Regards,
A.D.B.

Post a reply to this message

Am 08.08.2015 um 07:48 schrieb Anthony D. Baye:
> Does the source actually use the default power function from the cmath library?

To be precise, POV-Ray uses the "pow()" function declared in the 
standard <cmath> header file; what library this function is implemented 
in depends on the compiler and runtime environment.

For instance, and AFAIK, when compiling with Microsoft Visual Studio the 
function is implemented in the "tran.lib" library, while on Unix systems 
it is implemented in a library called "libm".

> It seems to me that I heard the default algorithm was actually somewhat
> inefficient.

That may well be: The default algorithm needs to fit certain precision 
constraints, /and/ be somewhat efficient in /all/ cases, so it is 
inevitable that there are cases in which a less-precise or less-generic 
algorithm would suffice and be faster.

Also, it may depend on the actual math library linked to, and/or the CPU 
architecture on which it is executed.


That said, the total time POV-Ray spends executing calls to pow() is 
probably far too low to warrant spending any energy on trying to figure 
out which of those calls can be replaced with a faster implementation. 
By far, most exponentiation in raytracing is squaring and taking the 
square root, for which POV-Ray already uses specialized functions 
(currently the "x*x" idiom in the case of squaring, and the sqrt() 
function from <cmath> for taking the square root).

Likewise, looking at the SDL pow() function, POV-Ray spends far more 
time parsing the SDL statement than it does actually computing the result.


Bottom line: Optimization /may/ be possible, but I strongly suspect it's 
not worth bothering. I presume it isn't even worth bothering to examine 
whether it is worth bothering.

Post a reply to this message