3 ms·
exp(x) = exp(x.real()) * sincos(x.imag()) Anyway, it is the same algorithm as long as `x` is real. The reason for manually inlining exp(::Complex) and manually
by celrod 5y ago
exp(x) = exp(x.real()) * sincos(x.imag())
Anyway, it is the same algorithm as long as `x` is real.
The reason for manually inlining exp(::Complex) and manually decomposing the complex number into its real and imaginary parts is that `@tturbo` currently only supports real inputs.
Given types that it does not support, it will silently run the original loop single-threaded and optimized simply with `@inbounds @fastmath`.
I imagine in changing to cis or exp, you also switched to using complex numbers? If so, that would explain the dramatic slowdown.
If not, mind sharing your example, here or in an issue at LoopVectorization.jl?
It's planned that "some day" LoopVectorization will support complex numbers through the AbstractInterpreter interface, but this is probably still a ways off.
- cycomanic 5y agoI agree, that it's the same algorithm as long as it x is real. My point was that with this optimisation we give more information to this function than the comparable python function (or the other julia implementations), so it gains an advantage for optimising. Yes I was using complex inputs when switching to to cis/exp. LoopVectorization not supporting complex does explain this. As a side note, I generally dislike silent fall-backs, for optimisation libraries/modules. That's why I always do python=False when using numba (and I wish it was default). I'm using the library/module because I want speed up, the problem with the fall-backs is they are often slower than the default code (e.g. unwrapped loops in numba, and in this example), so I would like to know if it doesn't speed up the code, because rather not use it then. A failure would save me benchmarking the slow-down.
- eigenspace 5y agoHere’s the code for the fully complex case: https://discourse.julialang.org/t/i-just-decided-to-migrate-from-python-fortran-to-julia-as-julia-was-faster-in-my-test/61188/19 https://discourse.julialang.org/t/i-just-decided-to-migrate-... Hopefully after the LoopVectoruzation.jl rewrite we can make it understand complex numbers automatically. We could probably put in special-case complex support today, but we’d really like to support arbitrary structs of bits.