Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Beware of fast-math

simonbyrne.github.io

Post reply on HN
Print view View original

91–100 of 111 posts

Re: Beware of fast-math

#91

Post by adrian_b »

jcelerier wrote: post #89
adrian_b wrote: post #86

Earlier quoted context omitted.

This is strange, so it is likely that it might be more of a Java problem than a CPU problem. I do not know how Java handles this, but maybe it actually enables exceptions for underflow which invoke some handler. Otherwise I cannot see how you can obtain such a huge slowdown, unless your code consists entirely of back-to-back operations with denormals and of nothing else. I am not sure what you mean by "state variable…

> unless your code consists entirely of back-to-back operations with denormals and of nothing else. Ending with the data being entirely in the denormal range is a common occurrence in some audio algorithms (and in there, intel CPUs dominate by such a large margin it's not even funny) ; if that happens at the beginning of your signal processing pipeline you're in for a rough time

I agree that this happens, but solving such cases with FTZ is a lazy solution, which is guaranteed to give bad results, due to the loss of precision.

Even when 32-bit floating point is used, for a greater dynamic range and for a 24-bit precision, instead of using 16-bit fixed-point numbers, proper DSP algorithm implementations still need to use some of the techniques that are necessary with fixed-point number algorithms, i.e. suitable scale factors must be inserted in various places.

A correct implementation must avoid almost all underflows and overflows, by appropriate scalings.

Re: Beware of fast-math

#92

Post by a_e_k »

an1sotropy wrote: post #8
dmitrygr wrote: post #3

Contrarian waypoint: beware of not-fast-math. Making things like atan2f and sqrtf set errno takes you down a very slow path, costing you significant perf in cases where you likely do not want it. And most math will work fine with fast-math, if you are careful how you write it. (Free online numerical methods classes are available, eg [1]) Without fast-math most compilers cannot even use FMA instructions (costing you u…

(in case anyone reading doesn't know: FMA = Fused Multiply and Add, as in a*b+c, an operation on 3 values, which increases precision by incurring rounding error once instead of twice) I'm not an expert on this, but for my own code I've been meaning to better understand the discussion here [1], which suggests that there ARE ways of getting FMAs, without the sloppiness of fast-math. [1] https://stackoverflow.com/questi…

C99 [0] and C++11 [1] both have fma() functions that let you directly request it without the need to mess around with sloppier FP contracts to infer it.

[0] https://en.cppreference.com/w/c/numeric/math/fma

[1] https://en.cppreference.com/w/cpp/numeric/math/fma

Re: Beware of fast-math

#93

Post by jcelerier »

adrian_b wrote: post #91
jcelerier wrote: post #89

Earlier quoted context omitted.

> unless your code consists entirely of back-to-back operations with denormals and of nothing else. Ending with the data being entirely in the denormal range is a common occurrence in some audio algorithms (and in there, intel CPUs dominate by such a large margin it's not even funny) ; if that happens at the beginning of your signal processing pipeline you're in for a rough time

I agree that this happens, but solving such cases with FTZ is a lazy solution, which is guaranteed to give bad results, due to the loss of precision. Even when 32-bit floating point is used, for a greater dynamic range and for a 24-bit precision, instead of using 16-bit fixed-point numbers, proper DSP algorithm implementations still need to use some of the techniques that are necessary with fixed-point number algorit…

the problem is (speaking from the end user side), you can't guarantee that every plug-in you are going to use is going to be coded properly - and you don't want that 2007 plug-in whose author has been dead for a decade but is super important for your sound to bring your whole performance down when it gets silence-ish input

Re: Beware of fast-math

#94

Post by physicsguy »

mhh__ wrote: post #60
physicsguy wrote: post #42

Earlier quoted context omitted.

You can do that on a per-compiler basis for e.g. with #pragma GCC optimize(“fast-math")

Hopefully it still works as an attribute but my point is that you can (say) opt in to allowing more liberal use of FMA without (say) opting in to aggressive NaN assumptions

Fast math is a collection of optimisations, you can enable them individually. You just have to look up what the appropriate ones are

Re: Beware of fast-math

#95

Post by spacechild1 »

nitrogen wrote: post #88
adrian_b wrote: post #86

Earlier quoted context omitted.

This is strange, so it is likely that it might be more of a Java problem than a CPU problem. I do not know how Java handles this, but maybe it actually enables exceptions for underflow which invoke some handler. Otherwise I cannot see how you can obtain such a huge slowdown, unless your code consists entirely of back-to-back operations with denormals and of nothing else. I am not sure what you mean by "state variable…

entirely of back-to-back operations with denormals In the context of sound, I could see this happening with an exponentially decaying envelope generator (or an IIR filter).

Yes. It is very easy to accidentally produce denormals in recursive audio algorithms.

Re: Beware of fast-math

#97

Post by gmueckl »

diamondlovesyou wrote: post #85
simonbyrne wrote: post #53

Earlier quoted context omitted.

Do you know what happens when you have ops with different flags? e.g. if you have (a + b) + c, where one + allows reassoc but one doesn't?

(a+b)+c has two ops in LLVM: addition is a bin op, meaning it has two "arguments", thus (a+b) and adding "c" are separate instructions. You can't directly add three or more values.

I believe the parent wants to know how a sequence of IR instructions with alternating modes is translated to the target.

My guess would be that explicit state state changes show up in the generated machine code.

Re: Beware of fast-math

#98

Post by krylon »

headPoet wrote: post #50

-funsafe-math-optimizations always makes me laugh. Of course I want fun and safe math optimisations

They're not fun and safe, though, they're "fun-safe", so you don't enjoy yourself (too much) while doing math.

Re: Beware of fast-math

#99

Post by an1sotropy »

a_e_k wrote: post #90
dahart wrote: post #82

Earlier quoted context omitted.

You know, that is actually ringing a bell, I think I might have indeed. Above I was thinking of someone else who works on a certain renderer made in New Zealand, but it’s true that many studios using doubles either sparingly or not at all. That might be getting even more true as GPUs blend into production…

I worked on a certain hopping lamp renderer for more than 11 eleven years. I can confirm that probably 99+% of the floating point math in it was in single precision. And to this day, typing out the 'f' suffix on single precision literals is muscle memory for me after having had Steven Parker for my Ph.D. advisor.

In the coding framework I created for students we have a "real" typedef that is either for float or double, and with C99's you just write "cos" once, and it will turn into cosf or cos depending on how the typedef is set, which allows controlled experimentation on how FP precision affects performance. But for submitted code the grading scripts grep for "double" and turn on various extra warnings to ensure that there are no implicit casts from double to float, in an effort to ensure that single precision is always being used (but I should probably scan the assembly).

Steve Parker was the first person to explain to me (while he was still a student, and I was a much younger one) the sometimes surprising cost of having image sizes be powers of two (because of cache conflicts). Small world.

Re: Beware of fast-math

#100

Post by willis936 »

adgjlsfhk1 wrote: post #48
willis936 wrote: post #46

I use single precision floating point to save memory and computation in applications where it makes sense. I had a case where I didn't care about the vertical precision of a signal very much. It had a sample rate in the tens of thousands of samples per second. I was generating a sinusoid and transmitting it. On the receiver the signal would become garbled after about a minute. I slapped my head and immediately realiz…

IMO, sinpi(x)=sin(pi*x) is a better function because it does much better here. the regular trig functions are approximately 20% slower for most implementations in order to accurately reduce mod 2pi, while reducing mod 2 is pretty much trivial.

Also, thanks. I had not heard of this function before, but apparently it was added to MATLAB in 2018.
Post reply on HN