4 ms·

I wonder how much these apply to the Julia compiler: based on the docs for `@simd` and the writing here [1], only the first two criteria on this page [2] seem t

I wonder how much these apply to the Julia compiler: based on the docs for `@simd` and the writing here [1], only the first two criteria on this page [2] seem to be really a requirement in Julia's case. The one about avoiding function calls is a no-go, since things like + and * are function calls too. But is it still required for all function calls to be inline-able? Indirect indexing isn't mentioned in Julia's case, but is it one of the things that would disable auto-vectorization and require an explicit @simd annotation? [1] https://viralinstruction.com/posts/hardware/#74a3ddb4-8af1-11eb-186e-4d80402adfcf https://viralinstruction.com/posts/hardware/#74a3ddb4-8af1-1... [2] https://cvw.cac.cornell.edu/vector/coding_vectorizable https://cvw.cac.cornell.edu/vector/coding_vectorizable

celrod 3y ago
Yes, it is required for all functions to be inlined in Julia. Note that Julia 1.8 and newer supports callsite inlining, so you can, for example, do `@inline exp(x[i])` inside your `for` loop, and this will cause `exp` to get inlined there, and should enable vectorization. For functions like `log` or `sin`, this is not enough, but you could try `@turbo` from LoopVectorization.jl, which supports these and some others. `@simd ivdep` may be needed when you have indirect indexing. Do not forget the `ivdep`, but only if you know it is actually safe. This can lead to hard to track down bugs if it is not.
oersted 3y ago
[flagged]
- celrod 3y ago
  Is this GPT-generated crap? It is wrong and useless, like GPT always is, but sounds intelligent to fool the ignorant. The compiler can inline functions, but it is essential for it to do so. It does not adjust heuristics based on being in a loop. Hence, manual intervention like `@inline` is often needed for non-trivial cases, such as `exp`. `@simd` doesn't say vectotization is desired, which implies changing heuristics. It adds flags to reduction variables to say it is legal to reassociate them. That does not help at all with indirect indexing. `@simd ivdep` does help by communicating it is legal to perform the loop iterations in parallel, meaning the legality checks are no longer required. The functions must still be inlined for it to succeed in generating vectorized code.
  - oersted 3y ago
    Yes, my bad. This is a bit far from my expertise, so I was trying out MirrorThink to understand what was being discussed. This reply seemed constructive so I copied it over, clearly I should have verified it better.

celrod 3y ago

Yes, it is required for all functions to be inlined in Julia. Note that Julia 1.8 and newer supports callsite inlining, so you can, for example, do `@inline exp(x[i])` inside your `for` loop, and this will cause `exp` to get inlined there, and should enable vectorization. For functions like `log` or `sin`, this is not enough, but you could try `@turbo` from LoopVectorization.jl, which supports these and some others. `@simd ivdep` may be needed when you have indirect indexing. Do not forget the `ivdep`, but only if you know it is actually safe. This can lead to hard to track down bugs if it is not.

oersted 3y ago

[flagged]

celrod 3y ago
Is this GPT-generated crap? It is wrong and useless, like GPT always is, but sounds intelligent to fool the ignorant. The compiler can inline functions, but it is essential for it to do so. It does not adjust heuristics based on being in a loop. Hence, manual intervention like `@inline` is often needed for non-trivial cases, such as `exp`. `@simd` doesn't say vectotization is desired, which implies changing heuristics. It adds flags to reduction variables to say it is legal to reassociate them. That does not help at all with indirect indexing. `@simd ivdep` does help by communicating it is legal to perform the loop iterations in parallel, meaning the legality checks are no longer required. The functions must still be inlined for it to succeed in generating vectorized code.
- oersted 3y ago
  Yes, my bad. This is a bit far from my expertise, so I was trying out MirrorThink to understand what was being discussed. This reply seemed constructive so I copied it over, clearly I should have verified it better.