101–110 of 132 posts
Your own compiled library functions will use the optimizations, but won't force the weird FPU register modes on the rest of the process.
Earlier quoted context omitted.
Automatic FMA can change the result of operations, so it makes (some) sense to be bundled in with fastmath.
But if what you want is automatic FMA, then why carry along every other possible behavior with it? Just because you want FMA, suddenly NaNs are turned into Infs, subnormal numbers go to zero, handling of sin(x) at small values is inaccurate, etc? To me that's painting numerical handling in way too broad of strokes. FMA also only increases numerical accuracy, it doesn't decrease numerical accuracy, so bundling it with…
In D you can opt into specific float algorithms locally rather than a compiler flag. Use of fast math can really really really bite you sometimes, so just being able to opt into using fma and nothing else is awesome.
Earlier quoted context omitted.
Anyway, since there aren't any dependencies between a, b, c, and d, I would expect the two divisions to end up basically in parallel in the pipeline. So the critical path is a division and a multiplication either way. Of course that is just a guess.
That assumes you can do multiple divisions in parallel. Back in the good old days, a single division unit was the norm, and it still is on most microcontrollers (assuming they even have hardware floating-point division[1]). Anyone have any references on how the current state of affairs on modern AMD/Intels? [1]: ARM Cortex-M4 for example can have a hardware FPU, but where division and sqrt are optional, see https://d…
Looks like one FP divider on modern intel. Though you can pack multiple divisions into an instruction.
For AMD I can find throughput numbers but not how many there are, in a brief search. I'd guess two??
The problem here is that enabling FTZ/DAZ flags involves modifying global (technically thread-local) state that is relatively expensive to do. Ideally, you'd want to twiddle these flags only for code that wants to work in this mode, but given the relative expense of this operation, it's not entirely practicable to auto-add twiddling to every function call, and doing it manually is somewhat challenging because compile…
I don't think flipping these flags is expensive. Can you provide a source for that? AFAICT modern microarchitectures are going to register-rename that into the u-ops issued to the functional units, rather than flush the entire ROB.
Keep in mind that twiddling these flags is going to require saving the MXCSR register to memory, or'ing or and'ing bits in memory, and then reading that memory back into MXCSR. And both saving and reading the MXCSR requires stalls, because floating point operations both read and write that register. So you require, minimum, 4 L1 cache hits and 2 partial pipeline flushes to twiddle a MXCSR bit.
(As far as I'm aware, modern microarchitectures generally don't register-rename the floating-point status register.)
It's -ffast-math isn't it?
...
Yep. That option is a candy coated foot gun.
Earlier quoted context omitted.
I don't think flipping these flags is expensive. Can you provide a source for that? AFAICT modern microarchitectures are going to register-rename that into the u-ops issued to the functional units, rather than flush the entire ROB.
https://www.agner.org/optimize/instruction_tables.pdf , search for MXCSR (LDMXCSR and STMXCSR instructions). Keep in mind that twiddling these flags is going to require saving the MXCSR register to memory, or'ing or and'ing bits in memory, and then reading that memory back into MXCSR. And both saving and reading the MXCSR requires stalls, because floating point operations both read and write that register. So you req…
Note that you wouldn't necessarily need to do a read-modify-write -- it'd suffice in most cases to just to save the old value and then reset the whole MXCSR for the scope requiring special treatment.
Earlier quoted context omitted.
Automatic FMA can change the result of operations, so it makes (some) sense to be bundled in with fastmath.
This isn't really as valid a comparison as you might think it is. The results of operations varying is not the problem with 'fast-math', the problem is that can negatively impact accuracy in catastrophic ways (among other things). Sure, automatic FMA can change the result, but to my knowledge it always gives a more accurate result, not a less accurate one, and the way in which the results may differ is bounded.
Earlier quoted context omitted.
https://www.agner.org/optimize/instruction_tables.pdf , search for MXCSR (LDMXCSR and STMXCSR instructions). Keep in mind that twiddling these flags is going to require saving the MXCSR register to memory, or'ing or and'ing bits in memory, and then reading that memory back into MXCSR. And both saving and reading the MXCSR requires stalls, because floating point operations both read and write that register. So you req…
Looks like many x86 cores still do rename MXCSR, though Gracemont notably doesn't: https://chipsandcheese.com/2021/12/21/gracemont-revenge-of-t... Note that you wouldn't necessarily need to do a read-modify-write -- it'd suffice in most cases to just to save the old value and then reset the whole MXCSR for the scope requiring special treatment.
Earlier quoted context omitted.
That assumes you can do multiple divisions in parallel. Back in the good old days, a single division unit was the norm, and it still is on most microcontrollers (assuming they even have hardware floating-point division[1]). Anyone have any references on how the current state of affairs on modern AMD/Intels? [1]: ARM Cortex-M4 for example can have a hardware FPU, but where division and sqrt are optional, see https://d…
https://en.wikichip.org/wiki/intel/microarchitectures/sunny_... Looks like one FP divider on modern intel. Though you can pack multiple divisions into an instruction. For AMD I can find throughput numbers but not how many there are, in a brief search. I'd guess two??