3 ms·

Yikes. A lot of code uses _mm_rsqrt_ps (sometimes) followed by a Newton-raphson update to compute a "precise" 1/sqrt(x). Here's a good example of NEON's rsqrt

by boulos 5y ago

Yikes. A lot of code uses _mm_rsqrt_ps (sometimes) followed by a Newton-raphson update to compute a "precise" 1/sqrt(x). Here's a good example of NEON's rsqrt being sufficiently different from Intel, that more iterations were necessary for Embree on ARM [1]. Because I only cared about vectorization a long time ago, and AMD was so uncompetitive then, I'd bet a lot of code assumes that the SSE rsqrtps values match. [1] https://github.com/lighttransport/embree-aarch64/issues/20 https://github.com/lighttransport/embree-aarch64/issues/20

boulos 5y ago
(Too late for edit) Looks like Eigen also defaults to EIGEN_FAST_MATH which makes Eigen's psqrt ("packet sqrt") use _mm256_rsqrt_ps instead of _mm256_sqrt_ps [1]. Interestingly, the thing they're trying to avoid (long latency of sqrt vs rsqrt) hasn't been true for a long time on Intel processors, but apparently is still true for AMD parts according to Agner Fog's tables [2] (though maybe I'm reading them wrong, there is no vsqrtps entry for Zen2/3). Hopefully, Eigen will separate the single global "fast math" config [3]. [1] https://gitlab.com/libeigen/eigen/-/blob/a75122584594fb98db09d1665b5b39c98b2b967d/Eigen/src/Core/arch/AVX/MathFunctions.h#L110 https://gitlab.com/libeigen/eigen/-/blob/a75122584594fb98db0... [2] https://agner.org/optimize/instruction_tables.pdf https://agner.org/optimize/instruction_tables.pdf [3] https://gitlab.com/libeigen/eigen/-/issues/1687 https://gitlab.com/libeigen/eigen/-/issues/1687