Indeed, I spent a bit of time chasing this too. I created this benchmark:
# v1.8.0
x = rand(ComplexF32,1000); y = similar(x);
u = similar(x, UInt64); v = similar(u);
conjmask = reinterpret(UInt64,[conj(zero(ComplexF32))]) |> only
reinterpcopy!(y,x) = copy!(y,reinterpret(eltype(y),x))
using BenchmarkTools
@btime broadcast!(conj,$y,$x);
# 679.221 ns (0 allocations: 0 bytes)
@btime broadcast!(xor,$v,$u,$conjmask);
# 65.814 ns (0 allocations: 0 bytes)
@btime reinterpcopy!($y, broadcast!(xor,$v,reinterpcopy!($u,$x),$conjmask));
# 676.923 ns (0 allocations: 0 bytes)
The first two tests do the exact same bit transformations to the input arrays, although the UInt version manages to SIMD and unroll and achieves a 10x speedup.
I tried to write a version using reinterpret(UInt64, x::ComplexF32) per-element, but #42968.
Instead, the third one bit-copies the Complex array into the UInt array, does the operation between the UInt arrays, then copies the result back to a Complex array. It takes the same amount of time as the pure float version even with two extra unfused copies.
I don’t have the expertise to say whether this is a Julia issue or an LLVM issue. The relevant definition is conj(z::Complex) = Complex(real(z),-imag(z)), but I’d be loath to write that any other way within Julia.
The @code_llvm does maybe suggest that Julia could generate better LLVM?
@code_llvm conj(2.0im)
; @ complex.jl:276 within `conj`
define void @julia_conj_7225([2 x double]* noalias nocapture sret([2 x double]) %0, [2 x double]* nocapture
nonnull readonly align 8 dereferenceable(16) %1) #0 {
top:
; ┌ @ complex.jl:72 within `real`
; │┌ @ Base.jl:38 within `getproperty`
%2 = getelementptr inbounds [2 x double], [2 x double]* %1, i64 0, i64 0
; └└
; ┌ @ complex.jl:87 within `imag`
; │┌ @ Base.jl:38 within `getproperty`
%3 = getelementptr inbounds [2 x double], [2 x double]* %1, i64 0, i64 1
; └└
; ┌ @ float.jl:381 within `-`
%4 = load double, double* %3, align 8
%5 = fneg double %4
; └
; ┌ @ complex.jl:14 within `Complex` @ complex.jl:14
%6 = load double, double* %2, align 8
; └
%.sroa.0.0..sroa_idx = getelementptr inbounds [2 x double], [2 x double]* %0, i64 0, i64 0
store double %6, double* %.sroa.0.0..sroa_idx, align 8
%.sroa.2.0..sroa_idx1 = getelementptr inbounds [2 x double], [2 x double]* %0, i64 0, i64 1
store double %5, double* %.sroa.2.0..sroa_idx1, align 8
ret void
}
@code_llvm -(2.0im)
; @ complex.jl:287 within `-`
define void @julia_-_7227([2 x double]* noalias nocapture sret([2 x double]) %0, [2 x double]* nocapture nonnull readonly align 8 dereferenceable(16) %1) #0 {
top:
; @ complex.jl:287 within `-` @ float.jl:381
%2 = bitcast [2 x double]* %1 to <2 x double>*
%3 = load <2 x double>, <2 x double>* %2, align 8
%4 = fneg <2 x double> %3
; @ complex.jl:287 within `-`
%5 = bitcast [2 x double]* %0 to <2 x double>*
store <2 x double> %4, <2 x double>* %5, align 8
ret void
}
Notice the getelementptr business that is generated for conj but not -. That may be getting in the way of proper optimization? The @code_native seems to reflect this difference.
I don’t have significant knowledge or understanding of LLVM, so can’t say whether Julia’s generated LLVM is truly the issue. But whether it’s Julia or LLVM, there’s definitely a potential performance improvement that could come out of this. Surely, there are many other cases where we’re similarly suboptimal.
EDIT: The plot thickens. Duplicating the definition of conj seems to be giving a signficant (but still partial) improvement. What’s going wrong with the normal one?
# v1.8.0
conj_duplicate(z::Complex) = Complex(real(z),-imag(z))
@btime broadcast!(conj_duplicate,$y,$x);
# 447.449 ns (0 allocations: 0 bytes)