pow() vs powf()

[sezero]

In internal_midi.c:_WM_AdjustNoteVolumes() we use powf() and floats instead
of plain old pow(). Is there a specific reason? Is the extra precision harmful?

[psi29a]

scratch this comment as redundant of the above.

Do we gain anything from using pow?

• Does it effect the result?
• Is it more CPU intensive than powf?

[sezero]

Do we gain anything from using pow?

pow() is ansi, powf() is c99. My question remains, i.e.
what do we gain anything from using powf()?

Is it more CPU intensive than powf?

For x86, it shouldn't be.

[psi29a]

You mean standard C or ANSI C?

By default, Microsoft's Visual Studio C Compiler doesn't follow the ANSI C standard.

[sezero]

I meant C89, i.e. available practically in every and all libc

[psi29a]

Good. :)

As you mentioned for x86 that there shouldn't be any overhead, how about our armhf friends (nintendo3dsdevkit and raspberry pi) ?

[sezero]

Not just arm, but ppc and any others. (Hope that anyone's listening.)
And we'd like to hear what @chrisisonwildcode has to say (his code and
that's the reason I assigned this to him.)

[chrisisonwildcode]

I will have a look

…

Sent from my iPhone

On 15 Feb 2017, at 10:05 pm, sezero ***@***.***> wrote: Do we gain anything from using pow? pow() is ansi, powf() is c99. My question remains, i.e. what do we gain anything from using powf()? Is it more CPU intensive than powf? For x86, it shouldn't be. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or mute the thread.

[sezero]

I will have a look

Had any chance to look?

[chrisisonwildcode]

Oops, sorry guys. I've got to finish a research assessment *low grumbling about large word counts* and I will look at this when I get back from town today. Chris

…

Sent from my iPhone

On 1 Mar 2017, at 7:24 am, sezero ***@***.***> wrote: I will have a look Had any chance to look? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[sezero]

PING ?

[psi29a]

@chrisisonwildcode any ideas on this?

[sezero]

I guess this question will go unanswered for quite a long time...

[chrisisonwildcode]

I have an idea what is going on. 0.4 reworked a lot of the code. There is a flaw in tracking timing changes in the initial read of the midi file. A simular flaw occurs also in devtest.c

…

Sent from my iPhone

On 26 Jul 2017, at 5:38 pm, Bret Curtis ***@***.***> wrote: @chrisisonwildcode any ideas on this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[psi29a]

Hmmm.. :)

[sezero]

I have an idea what is going on. 0.4 reworked a lot of the code. There is a flaw
in tracking timing changes in the initial read of the midi file. A simular flaw
occurs also in devtest.c

I believe your comment was intended for bug #176, yes?

[psi29a]

Something interesting, using pow(x, 3) is more cpu intensive than just x * x * x, apparently even modern gcc and clang behave the same for float (powf). We could move to double (pow) and use --fast-math, which give us a speed boost (no overhead compared to x * x * x).

https://baptiste-wicht.com/posts/2017/09/cpp11-performance-tip-when-to-use-std-pow.html

If you are using double precision (double), std::pow(x, n) will be slower than the handcrafted equivalent unless you use -ffast-math, in which case, there is absolutely no overhead. The overhead without using the compiler option is quite large, around 2 orders of magnitude, starting from the third power. With or without -ffast-math, std::pow(x, 2) has no overhead compared to x * x.

For single precision, it's another story! For the two compilers that have been tested and for small integer values of n (but I think it's stays the same for large integer values of n), it's always faster to use direct multiplication rather than exponentiation via std::pow(x, n). Indeed, it seems that there is no optimization for the case when n is an integer. When -ffast-math is used, the difference it not very big, around 2.5 times slower for GCC and around 3.5 times slower for clang. I'm a bit disappointed by the lack of single-precision performance for std::pow. Basically, you should not use std::pow if you want single-precision powers.

[chrisisonwildcode]

hmmm, I can't see why we couldn't use pow() in there. … can we get -ffast-math happening?