-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
slowdown of atomics on 0.7 / fix llvmcall
#27694
Comments
Looks like bad lowering (the call expression isn't getting linearized). The |
llvmcall
Adding to 1.0.x; a couple times I've run into cases where poking the compiler a bit causes it to blow up on llvmcall due to its un-settled IR form. |
The following reproduces the bug and shows a workaround:
|
Will/can this be addressed any time soon? |
Also julia> VERSION
v"0.6.4"
julia> using BenchmarkTools
julia> l = Threads.SpinLock()
Base.Threads.TatasLock(Base.Threads.Atomic{Int64}(0))
julia> f(l) = (Threads.lock(l); Threads.unlock(l))
f (generic function with 1 method)
julia> @btime f($l)
9.116 ns (0 allocations: 0 bytes) julia> VERSION
v"0.7.0-beta.212"
julia> using BenchmarkTools
julia> l = Threads.SpinLock()
Base.Threads.TatasLock(Base.Threads.Atomic{Int64}(0))
julia> f(l) = (Threads.lock(l); Threads.unlock(l))
f (generic function with 1 method)
julia> @btime f($l)
192.185 ns (3 allocations: 48 bytes)
|
Adding to 0.7 since this blocks SIMD.jl. |
Somehow all atomics became really slow and allocating. Example:
This is very visible when inspecting
@code_llvm
: Instead of the hand-written llvmcall, we get some weird giant blob of compiler output.The text was updated successfully, but these errors were encountered: