3 ms·
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
by 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 agoThe 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 agousing 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