8 ms·

to me this feels like wasted effort due to solving the wrong problem. The extra half ulp error makes no difference to the accuracy of calculations. the problem

to me this feels like wasted effort due to solving the wrong problem. The extra half ulp error makes no difference to the accuracy of calculations. the problem is that languages traditionally rely on an OS provided libm leading to cross architecture differences. If instead, languages use a specific libm, all of these problems vanish.

lifthrasiir 6mo ago
Standardizing a particular libm essentially locks any further optimizations because that libm's implementation quirks have to be exactly followed. In comparison the "most correct" (0.5 ulp) answer is easy to standardize and agree upon.
fweimer 6mo ago
Many of the conversions so far have been clearly faster. I don't think anything has been merged which shows a clear performance regression, at least not on CPUs with FMA support.
- gajjanag 6mo ago
  The bigger challenge is GPU/NPU. Branches for fast vs accurate path get costlier, among other things. On CPU this is less of a cost. Most published libm on GPU/NPU side have a few ULP of error for the perf vs accuracy tradeoff. Eg, documented explicitly in the CUDA programming guide: https://docs.nvidia.com/cuda/cuda-programming-guide/05-appendices/mathematical-functions.html https://docs.nvidia.com/cuda/cuda-programming-guide/05-appen... . Prof. Zimmermann and collaborators have a great table at https://members.loria.fr/PZimmermann/papers/accuracy.pdf https://members.loria.fr/PZimmermann/papers/accuracy.pdf (Feb 2026) comparing various libm wrt accuracy.
- adgjlsfhk1 6mo ago
  using fma makes it possible to write faster libm functions, but going back to a 1 ulp world with the same fma optimizations would give you another 20% speedup at least. the other issue is that these functions tend to have much larger code size which tends not to be a significant problem in micro benchmarks, but means that in real applications you increase cache pressure allowing things down in aggregate
ghighi7878 6mo ago
Mixed precision computations need correctly rounded functions.
- adgjlsfhk1 6mo ago
  no they don't... why would they?
SideQuark 6mo ago
> The extra half ulp error makes no difference to the accuracy of calculations It absolutely does matter. The first, and most important reason, is one needs to know the guarantees of every operation in order to design numerical algorithms that meet some guarantee. Without knowing that the components provide, it's impossible to design algorithms on top with some guarantee. And this is needed in a massive amount of applications, from CAD, simulation, medical and financial items, control items, aerospace, and on and on. And once one has a guarantee, making the lower components tighter allows higher components to do less work. This is a very low level component, so putting the guarantees there reduces work for tons of downstream work. All this is precisely what drove IEEE 754 to become a thing and to become the standard in modern hardware. > the problem is that languages traditionally rely on an OS provided libm leading to cross architecture differences No, they don't not things like sqrt and atanh and related. They've relied on compiler provided libs since, well, as long as there have been languages. And the higher level libs, like BLAS, are built on specific compilers that provide guarantees by, again, libs the compiler used. I've not seen OS level calls describing the accuracy of the floating point items, but a lot of languages do, including C/C++ which underlies a lot of this code.
- adgjlsfhk1 6mo ago
  > The first, and most important reason, is one needs to know the guarantees of every operation in order to design numerical algorithms that meet some guarantee sure, but a 1 ulp guarantee works just as well here while being substantially easier to provide. > And the higher level libs, like BLAS, are built on specific compilers that provide guarantees Sure, but Blas doesn't provide any accuracy guarantees so it being built on components that sort of do has pretty minimal value for it. For basically any real application, the error you experience is error from the composition of intrinsics, not the composed error of those intrinsic themselves, and that remains true even if those intrinsics have 10 ULP error or 0.5 ULP error

lifthrasiir 6mo ago

Standardizing a particular libm essentially locks any further optimizations because that libm's implementation quirks have to be exactly followed. In comparison the "most correct" (0.5 ulp) answer is easy to standardize and agree upon.

fweimer 6mo ago

Many of the conversions so far have been clearly faster. I don't think anything has been merged which shows a clear performance regression, at least not on CPUs with FMA support.

gajjanag 6mo ago
The bigger challenge is GPU/NPU. Branches for fast vs accurate path get costlier, among other things. On CPU this is less of a cost. Most published libm on GPU/NPU side have a few ULP of error for the perf vs accuracy tradeoff. Eg, documented explicitly in the CUDA programming guide: https://docs.nvidia.com/cuda/cuda-programming-guide/05-appendices/mathematical-functions.html https://docs.nvidia.com/cuda/cuda-programming-guide/05-appen... . Prof. Zimmermann and collaborators have a great table at https://members.loria.fr/PZimmermann/papers/accuracy.pdf https://members.loria.fr/PZimmermann/papers/accuracy.pdf (Feb 2026) comparing various libm wrt accuracy.
adgjlsfhk1 6mo ago
using fma makes it possible to write faster libm functions, but going back to a 1 ulp world with the same fma optimizations would give you another 20% speedup at least. the other issue is that these functions tend to have much larger code size which tends not to be a significant problem in micro benchmarks, but means that in real applications you increase cache pressure allowing things down in aggregate

ghighi7878 6mo ago

Mixed precision computations need correctly rounded functions.

adgjlsfhk1 6mo ago
no they don't... why would they?

SideQuark 6mo ago

> The extra half ulp error makes no difference to the accuracy of calculations It absolutely does matter. The first, and most important reason, is one needs to know the guarantees of every operation in order to design numerical algorithms that meet some guarantee. Without knowing that the components provide, it's impossible to design algorithms on top with some guarantee. And this is needed in a massive amount of applications, from CAD, simulation, medical and financial items, control items, aerospace, and on and on. And once one has a guarantee, making the lower components tighter allows higher components to do less work. This is a very low level component, so putting the guarantees there reduces work for tons of downstream work. All this is precisely what drove IEEE 754 to become a thing and to become the standard in modern hardware. > the problem is that languages traditionally rely on an OS provided libm leading to cross architecture differences No, they don't not things like sqrt and atanh and related. They've relied on compiler provided libs since, well, as long as there have been languages. And the higher level libs, like BLAS, are built on specific compilers that provide guarantees by, again, libs the compiler used. I've not seen OS level calls describing the accuracy of the floating point items, but a lot of languages do, including C/C++ which underlies a lot of this code.

adgjlsfhk1 6mo ago
> The first, and most important reason, is one needs to know the guarantees of every operation in order to design numerical algorithms that meet some guarantee sure, but a 1 ulp guarantee works just as well here while being substantially easier to provide. > And the higher level libs, like BLAS, are built on specific compilers that provide guarantees Sure, but Blas doesn't provide any accuracy guarantees so it being built on components that sort of do has pretty minimal value for it. For basically any real application, the error you experience is error from the composition of intrinsics, not the composed error of those intrinsic themselves, and that remains true even if those intrinsics have 10 ULP error or 0.5 ULP error