safer access to Julia's type inference #8
Conversation
|
Yeah, it seems an explicit world age parameter is required for |
|
NB: the Julia nightly CI job also fails on PR #9, which doesn't change any source code. I guess it might perhaps be possible to fix the test failure by providing the correct world age explicitly, however it also might be OK to leave that for a future PR, given that it doesn't regress here. |
|
My concern about this is that it's very slow. julia> @btime Base.infer_return_type(sin, Tuple{Float64})
454.411 ns (14 allocations: 784 bytes)
Float64That's twice as long as the time it takes to spawn a task julia> @btime Threads.@spawn 1
253.153 ns (4 allocations: 480 bytes)
Task (done) @0x00007fd60c07c010meaning that this change would cause substantial shifts in the window where various problems become amenable to multithreading, and also makes stuff like load balancing through the launching of many tasks unsustainable. The above benchmark was on v1.11, but I just tried on master and it's now another 10x slower than v1.11: julia> @btime Base.infer_return_type(sin, Tuple{Float64})
4.785 μs (54 allocations: 4.00 KiB)
Float64whereas julia> @btime Core.Compiler.return_type(sin, Tuple{Float64})
1.082 ns (0 allocations: 0 bytes)
Float64I'd be in favour of accepting this change though just without the |
| isdefined(Core.Compiler, :return_type) && | ||
| applicable(Core.Compiler.return_type, identity, Tuple{}) | ||
| ) | ||
| infer_return_type(@nospecialize f::Any) = Core.Compiler.return_type(f, Tuple{}) |
There was a problem hiding this comment.
one last question, is there much reason for the @nospecialize here? Won't that just potentially block inference?
There was a problem hiding this comment.
@nospecialize doesn't block inference, that's @nospecializeinfer. My reasoning is that the computation only happens at macro instantiation time, so there's not much reason to specialize.
There was a problem hiding this comment.
There was a problem hiding this comment.
Ah I see. I was always a bit shaky on what things @nospecialize blocked and what it didn't, but I see now the docstring actually has some good info on this, specifically about the lack of inference blocking.
* Only access an implementation detail of Julia when it's available,
falling back to `Any` as an accurate but possibly imprecise
approximation of the return type.
* Prefer `Base.infer_return_type` to `Core.Compiler.return_type`
* The former is more public than the latter:
* JuliaLang/julia#53105 (comment)
* Warning/TODO: both of these accept a world age as an optional
parameter, but differ (?) in the default value choice. Thus it
might be necessary to provide a world age explicitly, not sure.
Relevant links to the Julia code base:
* `Core.Compiler.return_type`:
* https://github.com/JuliaLang/julia/blob/99a764750ef4e53214f2247d186ff4aac4f91983/Compiler/src/typeinfer.jl#L1416-L1434
* `Base.infer_return_type`
* https://github.com/JuliaLang/julia/blob/99a764750ef4e53214f2247d186ff4aac4f91983/base/reflection.jl#L534-L601
nsajko
force-pushed
the
infer_return_type
branch
from
2b3c02c to
cfa00d3
Compare
|
Thanks! |
Anyas an accurate but possibly imprecise approximation of the return type.Relevant links to the Julia code base:
Core.Compiler.return_type: