github-starred/airwindows

Fork 0

mirror of https://github.com/airwindows/airwindows.git synced 2026-05-15 06:05:55 -06:00

[GH-ISSUE #33] CPU load #26

New issue

Closed

opened 2026-05-05 22:02:24 -06:00 by gitea-mirror · 2 comments

gitea-mirror commented

2026-05-05 22:02:24 -06:00

Owner

Originally created by @sjaehn on GitHub (Jun 26, 2021).
Original GitHub issue: https://github.com/airwindows/airwindows/issues/33

Hi Chris,

I'm looking to speed up my ports of your Airwindows plugins as some of them are really hungry for CPU. I couldn't find too much. But there is one significant point to save CPU time. The pow() function. pow() is likely the most expensive of the standard <cmath> functions. Even more expensive than tan() on the most of the CPUs.

Thus, it's much faster to code x*x instead of pow(x,2). And also x*x*x and x*x*x*x are faster than pow(). OK, modern compilers PLUS optimization flags (-O3 AND -ffast-math) may end up at the same. But there is a big difference without optimization. See https://stackoverflow.com/questions/2940367/what-is-more-efficient-using-pow-to-square-or-just-multiply-it-with-itself .

And even bigger differences are for integer pow(2,x) versus bit shifting (1 << x). As in the stereo floating point dither section. See https://stackoverflow.com/questions/12556906/are-2n-exponent-calculations-really-less-efficient-than-bit-shifts .

I was able to save some 1/10 to 1/5 of the DSP load for XRegion by substituting the pow() functions.

Originally created by @sjaehn on GitHub (Jun 26, 2021). Original GitHub issue: https://github.com/airwindows/airwindows/issues/33 Hi Chris, I'm looking to speed up my ports of your Airwindows plugins as some of them are really hungry for CPU. I couldn't find too much. But there is one significant point to save CPU time. The `pow()` function. `pow()` is likely the most expensive of the standard `<cmath>` functions. Even more expensive than `tan()` on the most of the CPUs. Thus, it's much faster to code `x*x` instead of `pow(x,2)`. And also `x*x*x` and `x*x*x*x` are faster than `pow()`. OK, modern compilers PLUS optimization flags (`-O3` AND `-ffast-math`) may end up at the same. But there is a big difference without optimization. See https://stackoverflow.com/questions/2940367/what-is-more-efficient-using-pow-to-square-or-just-multiply-it-with-itself . And even bigger differences are for integer `pow(2,x)` versus bit shifting (`1 << x`). As in the stereo floating point dither section. See https://stackoverflow.com/questions/12556906/are-2n-exponent-calculations-really-less-efficient-than-bit-shifts . I was able to save some 1/10 to 1/5 of the DSP load for XRegion by substituting the `pow()` functions.

gitea-mirror closed this issue

2026-05-05 22:02:26 -06:00

gitea-mirror commented

2026-05-05 22:02:29 -06:00

Author

Owner

@sjaehn commented on GitHub (Jul 10, 2021):

Chris, you are right. As long as you compile with optimization flags (your default way), you are on the safe side for pow(). You correctly mentioned this in your last stream. But packagers and others who want to implement your plugins into sth. else (e.g., Surge) should keep their eyes open.

But there is still sth. else to safe CPU even in the presence of optimization flags. Omit type converting, if possible. float, double, and long double. Whereas the most of the floatand double operations are almost at the same speed for the most modern architectures, long double is still significantly slower. Unless, if you have a compiler that breaks down long double to double anyway ;-).

I was able to safe some 50% of CPU by brutal (= not generally recommended!) declaration of everything as float for XRegion plus remove of the floating point dither section.

@sjaehn commented on GitHub (Jul 10, 2021): Chris, you are right. As long as you compile with optimization flags (your default way), you are on the safe side for `pow()`. You correctly mentioned this in your last stream. But packagers and others who want to implement your plugins into sth. else (e.g., Surge) should keep their eyes open. But there is still sth. else to safe CPU even in the presence of optimization flags. Omit type converting, *if possible*. `float`, `double`, and `long double`. Whereas the most of the `float`and `double` operations are almost at the same speed for the most modern architectures, `long double` is still significantly slower. Unless, if you have a compiler that breaks down `long double` to `double` anyway ;-). I was able to safe some 50% of CPU by brutal (= not generally recommended!) declaration of everything as `float` for XRegion plus remove of the floating point dither section.

gitea-mirror commented

2026-05-05 22:02:31 -06:00

Author

Owner

@airwindows commented on GitHub (Jul 10, 2021):

You can of course do this as much as you like: it's MIT-licensed and you can make all your own versions, changed however you wish.

It will never be officially Airwindows style to run all the algorithms as single precision float. Ever. But if you did that, of course the floating point dither would be of no use to you :)

I do think it's possible that you'll run into some issues with some of the biquad stuff as biquads can have problems with low resolution numbers, but most things will still probably work. Some of the extreme control settings might crash your computer or produce artifacts if the algorithms are made to run on only floats, if the settings were exploiting the smaller amounts of error (expensively) gained in my versions.

@airwindows commented on GitHub (Jul 10, 2021): You can of course do this as much as you like: it's MIT-licensed and you can make all your own versions, changed however you wish. It will never be officially Airwindows style to run all the algorithms as single precision float. Ever. But if you did that, of course the floating point dither would be of no use to you :) I do think it's possible that you'll run into some issues with some of the biquad stuff as biquads can have problems with low resolution numbers, but most things will still probably work. Some of the extreme control settings might crash your computer or produce artifacts if the algorithms are made to run on only floats, if the settings were exploiting the smaller amounts of error (expensively) gained in my versions.

No labels

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/airwindows#26

No description provided.

Rows
Columns