Skip to content
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

Add some precompiles #29

Merged
merged 1 commit into from
Dec 24, 2020
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 19 additions & 0 deletions src/precompile.jl
Original file line number Diff line number Diff line change
@@ -1,3 +1,22 @@
function _precompile_()
ccall(:jl_generating_output, Cint, ()) == 1 || return nothing
for T in (Bool, Int, Float32, Float64)
for A in (Vector, Matrix)
precompile(stridedpointer, (A{T},))
end
end
function precompile_nt(@nospecialize(T))
for I ∈ (Int8, UInt8, Int16, UInt16, Int32, UInt32, Int64, UInt64)
precompile(vload_quote, (Type{T}, Type{I}, Symbol, Int, Int, Int, Int, Bool, Bool))
end
# precompile(vfmadd, (Vec{4, T}, Vec{4, T}, Vec{4, T})) # doesn't "take" (too bad, this is expensive)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any idea why it might not "take"?
Is there anything that can help?
The inference result for vfmadd(::Vec{W,T}, ::Vec{W,T}, ::Vec{W,T}) should trivially be Vec{W,T}.

Would defining the llvmcall functions to assert the return type in this manner help inference?

And, it also seems like inference should be easy for llvmcall(string_or_tuple, return_type, arg_types, args...) (i.e., return_type is the return type), so perhaps this is a Julia issue?

Copy link
Contributor Author

@timholy timholy Dec 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wish I knew. There are still some weird things about precompilation (e.g., JuliaLang/julia#38951) that need attention. This would be a prime candidate because this one MethodInstance (and its callees) costs you something like 200ms, which is quite a lot. (It looks like even more than that on the flamegraph, but that's because of other bits of codegen happening in the middle while this call-tree is being inferred.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, maybe the fact that codegen runs while the callees are being inferred could be related? No clue, really, just grasping for explanations.

Copy link
Member

@chriselrod chriselrod Dec 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still don't know very little about Julia's internals, so it's hard for me to speculate what will/will not work.

E.g., if there's any inference short circuiting that could quickly tell the return type of a function like:

@inline function (muladd(v1::Vec{W,T}, v2::Vec{W,T}, v3::Vec{W,T})::Vec{W,T}) where {W,T}
    _muladd(v1,v2,v3)
end
# define `_muladd` as the current definition of `muladd`, wrapping `llvmcall_expr`
# the `vfmadd` family calls `muladd`

that could then avoid descending into _muladd and having to evaluate llvmcall_expr to infer the (annotated) return type?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure. I would mostly just report this as an issue. I'm really hoping precompilation gets serious attention in Julia 1.7, we really are at the threshold of nuking the latency problem for many workloads.

end
U = NativeTypes
while isa(U, Union)
T, U = U.a, U.b
precompile_nt(T)
end
precompile_nt(U)
precompile(_pick_vector_width, (Type, Vararg{Type,100}))
precompile(>=, (Int, MM{4, 1, Int}))
end