131–140 of 152 posts
Earlier quoted context omitted.
I know almost nothing about compiler flags but I got a laugh out of this even though I still don't know if you're joking or not. Edit: Just read it again and now I understand the joke. Haha
don't forget libiberty which is linked in using -liberty (and freedom for all)
Earlier quoted context omitted.
I'm surprised by this, regarding sqrt. The standard stipulates correct rounding for simple arithmetic, including sqrt ever since 754 1985. Unless of course we are talking about the 80 bit format. If that's not the case, would be interested to know where they differ. Unfortunately for the transcendental function the accuracy still hasn't been pinned down, especially since that's still an ongoing research problem. Ther…
Because compilers can and have implemented sqrt in terms of rsqrt which is .. fun to work with. This also on SSE.
Every 754 architecture (including SSE) I've worked on has an accurate sqrt().
I'm assuming you're talking about with "fast math" enabled? In which case all bets are off anyway!
Earlier quoted context omitted.
I'm surprised by this, regarding sqrt. The standard stipulates correct rounding for simple arithmetic, including sqrt ever since 754 1985. Unless of course we are talking about the 80 bit format. If that's not the case, would be interested to know where they differ. Unfortunately for the transcendental function the accuracy still hasn't been pinned down, especially since that's still an ongoing research problem. Ther…
Because compilers can and have implemented sqrt in terms of rsqrt which is .. fun to work with. This also on SSE.
Now, there is also often an approximate rsqrt and approximate reciprocal, with varying degrees of accuracy, and that can be "fun."
Earlier quoted context omitted.
This advice is out-of-date. All CPU hardware nowadays conforms to IEEE 754 semantics for binary32 and binary64. (I think all the GPUs now have non-denormal-flushing modes, but my GPU knowledge is less deep). All compilers will have a floating-point mode that preserves IEEE 754 semantics assuming that FP exceptions are unobservable and rounding mode is the default, and this is usually the default (icc/icx is unusual i…
> It's actually not even all math library functions, just those that are like sin, pow, exp, etc., but specifically excluding things like sqrt. I'm still trying to come up with a good term to encompass these. Transcendental functions. They're called that because computing an exactly rounded result might be unfeasible for some inputs. https://en.wikipedia.org/wiki/Table-maker%27s_dilemma So standards for numerical com…
Earlier quoted context omitted.
> It's actually not even all math library functions, just those that are like sin, pow, exp, etc., but specifically excluding things like sqrt. I'm still trying to come up with a good term to encompass these. Transcendental functions. They're called that because computing an exactly rounded result might be unfeasible for some inputs. https://en.wikipedia.org/wiki/Table-maker%27s_dilemma So standards for numerical com…
While it is a difficult problem, it is not an infeasible problem nowdays, at least for trigonometric, logarithmic and exponential functions. ( All possible arguments have been mapped to prove how many additional bits are needed for correct rounding.) Two-argument pow remains an unsolved problem in my knowledge though.
There was a paper last year on binary64 pow (https://inria.hal.science/hal-04159652/document) which suggests that they have a correctly-rounded pow implementation, but I don't have enough technical knowledge to assess the validity of the claim.
Earlier quoted context omitted.
While it is a difficult problem, it is not an infeasible problem nowdays, at least for trigonometric, logarithmic and exponential functions. ( All possible arguments have been mapped to prove how many additional bits are needed for correct rounding.) Two-argument pow remains an unsolved problem in my knowledge though.
My understanding is we have exhaustively enumerated the unary binary32 functions and proved the correctness of correct-rounding for them. For binary64, exhaustive enumeration is not a viable strategy, but we generally have a decent idea of what cases end up being hard-to-round, and in a few cases, we may have mechanical proofs of correctness. There was a paper last year on binary64 pow ( https://inria.hal.science/hal…
[1] https://inria.hal.science/inria-00072594/document
> There was a paper last year on binary64 pow (https://inria.hal.science/hal-04159652/document) which suggests that they have a correctly-rounded pow implementation, but I don't have enough technical knowledge to assess the validity of the claim.
Thank you for the pointer. These were written by usual folks you'd expect from such papers (e.g. Paul Zimmermann) so I believe they did achieve significant improvement. Unfortunately it is still not complete, the paper notes that the third and final phase may still fail but is unknown whether it indeed occurs or not. So we will have to wait...
Earlier quoted context omitted.
Compilers often under-generate conditional instructions. They implicitly assume (correctly) that most branches you write are 90/10 (ie very predictable), not 50/50. The branches that actually are 50/50 suffer from being treated as being 90/10.
The branches in this example are not 50/50. Given a few million calls of clamp, most would be no-ops in practice. Modern CPUs are very good at dynamically observing this.
Earlier quoted context omitted.
The branches in this example are not 50/50. Given a few million calls of clamp, most would be no-ops in practice. Modern CPUs are very good at dynamically observing this.
Do you know that for a fact? For all calls of clamp? I have definitely used min and max when they are true 50/50s and I assume clamp also gets some similar use.
If your use case does not follow that pattern and you really care about performance, you have to pull out something like inline assembly.
Consider software like ffmpeg which have to do this for the sake of performance.
Earlier quoted context omitted.
-Ofast is one of those dangerous flags that you should probably be careful with. It is “contagious” and it can mess up code elsewhere in the program, because it changes processor flags. I would try a more specific flag like -ffinite-math-only.
Is that changing of global processor flags a x86 feature or does it hold for arm as well?
So, yes when targeting VFP math. NEON already always works in this mode though.
Earlier quoted context omitted.
> The results of your program will vary depending on the exact make of your compiler and other random attributes of your compile environment, which can wreak havoc if you have code that absolutely wants bit-identical results. This doesn't matter for everybody, but there are some domains where this can be a non-starter (e.g., multiplayer game code). This already shouldn't be assumed, because even the same code, compil…
This advice is out-of-date. All CPU hardware nowadays conforms to IEEE 754 semantics for binary32 and binary64. (I think all the GPUs now have non-denormal-flushing modes, but my GPU knowledge is less deep). All compilers will have a floating-point mode that preserves IEEE 754 semantics assuming that FP exceptions are unobservable and rounding mode is the default, and this is usually the default (icc/icx is unusual i…
Is this out of date?
https://developer.arm.com/documentation/den0018/a/NEON-Instr...