3 ms·
> But it then talks about how exp is implemented in hardware, in a way that forces it to be a non-SIMD calculation. The fact that exp is implemented in hardwar
by ta3401 2y ago
> But it then talks about how exp is implemented in hardware, in a way that forces it to be a non-SIMD calculation.
The fact that exp is implemented in hardware is not the argument. The argument is that exp is a library function, compiled separately, and thus the compiler cannot inline the function and fuse it with an array-wide loop, to detect later on an opportunity to generate the SIMD instructions.
It is true however that exp is implemented in hardware in the X86 world, and to be fair, perhaps a C compiler only needs to represent that function as an intrinsic instead, to give itself a chance to later replace it either with the function call or some SIMD instruction; but I guess that the standard doesn't provide that possibility?
- AlotOfReading 2y agoThe compiler can (and does) know enough about the stdlib functions to treat them specially. The C standard doesn't require that libm exist as a separately linked library either, that's just an implementation detail from an earlier time that got enshrined in POSIX.
- vmchale 2y ago> perhaps a C compiler only needs to represent that function as an intrinsic instead, to give itself a chance to later replace it either with the function call or some SIMD instruction I gesture to this in the blog post: > In C, one writes a function, and it is exported in an object file. To appreciate why this is special, consider sum :: Num a => [a] -> a in Haskell. This function exists only in the context of GHC. > ... > perhaps there are more fluent methods for compilation (and better data structures for export à la object files).
- ta3401 2y agoI now realize that I somewhat rephrased what was said in the blog. How strange!