Optimise usage of pow using fast equivalent and exp2

[Rossmaxx]

No description provided.

[LostRobotMusic]

Don't use fastPow in these cases, that approximation is extremely inaccurate and should only be used when precision isn't required. This is likely a major backwards compatibility break, always perform null tests with these things.

(Note that fastPow10 in contrast doesn't use an approximation and is therefore perfectly safe, despite the similar name.)

[DomClark]

I'd rather we used std::exp2, which will operate at the appropriate precision for its argument, than std::exp2f, which causes its argument to be implicitly converted to a float.

Also, in addition to Lost Robot's comment on the inaccuracy of the fastPow approximation, I would add that a lot of these cases are actually in UI code or file IO code, where performance doesn't matter nearly as much, and the cost of the computation is most likely dwarfed by other operations. As well as testing for regressions in behaviour, you should also profile the application before and after the changes to ensure we actually see a gain in performance in compensation for the reduction in accuracy.

[Rossmaxx]

I'd rather we used std::exp2,

Noted

, in addition to Lost Robot's comment on the inaccuracy of the fastPow approximation, I would add that a lot of these cases are actually in UI code or file IO code, where performance doesn't matter nearly as much, and the cost of the computation is most likely dwarfed by other operations.

I have reverted the of calls to fastPow. What exists now is calls to fastPow10f (mind the 10f). That function is accurate AND fast.

As well as testing for regressions in behaviour, you should also profile the application before and after the changes to ensure we actually see a gain in performance in compensation for the reduction in accuracy.

I don't have profiling set up in this branch. I'll try something tho.

[messmerd]

Haven't tested it, but it looks good

[Rossmaxx]

I couldn't see much performance improvement from profiling. @sakertooth do we still want this. Atleast there's no change in behaviour.

[sakertooth]

I couldn't see much performance improvement from profiling. @sakertooth do we still want this. Atleast there's no change in behaviour.

I generally always prefer using what is provided in the standard library by default. So, if the optimized pow function is not needed here, I personally would not want us to make the switch.

[Rossmaxx]

In some places, the updated pow function is needed but in other places, not really, but I would say, change everything as fastPow10f is accurate enough for the purpose unlike the other fastPow.

[Rossmaxx]

@sakertooth we fine with pushing this as is, or should I enforce the std::pow ?

[sakertooth]

My stance is the same still: I would prefer std::pow if something else isn't strictly necessary, but I am not entirely sure how others feel about this. @DomClark mentioned that most of these changes are within the UI code, where the performance gains from using something like a fast pow approximation is dwarfed by other operations that happen there, so I think using std::pow is the way to go here.

[Rossmaxx]

Should I revert the ones in monstro and Drumsynth too?

[Rossmaxx]

I didn't get an answer here. Even if i should make the change, I can't for now because my laptop display is gone (posted that story on discord).

I'm just a bit too enthusiastic to hit that button.

[sakertooth]

Apologies for the delay, I'm reviewing this right now @Rossmaxx.

[sakertooth]

LGTM overall, just a few suggestions. I also think it is okay to leave the fastPow10f changes in Monstro. Maybe not DrumSynth since we load .ds files on the main thread, so no need for an approximation there I would think. I'm not entirely sure though.