You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What surprises me most is the 2nd run. It should be instantaneous yet it shows a ~80% compile time. The profile shows that a large part of this time is spent in set operations (intersect, union and setdiff), which I can confirm that these are always set operations between Vector{Symbol}s, NTuple{N,Symbol} or Set{Symbol}. All the leaves of the flamegraph are calls to make_oc_dict, so @wsmoses could it be that we are not correctly caching the OpaqueClosures?
I tried adding @nospecializeinfer, @noinline and Base.inferencebarrier to my Tenet.contract specialization for TracedRArrays, but nothing. @reactant_overlay seems to make it disappear from the profile, but compile time remains the same.
It would be nice to have a better way to stop abstract interpretation at some points where we know that it's not worth it because we are already in a Reactant-specific method and we are just emitting MLIR ops, not tracing below.
CC @gbaraldi since I believe you're in charge of getting compile times down within the GB project.
The text was updated successfully, but these errors were encountered:
I'm trying to get down the time taken to compile Tenet.jl.
Right now I'm using this script:
I'm uploading the profiles of
@compile
here: tenet-profile-reactant-compile-run.zipWhat surprises me most is the 2nd run. It should be instantaneous yet it shows a ~80% compile time. The profile shows that a large part of this time is spent in set operations (intersect, union and setdiff), which I can confirm that these are always set operations between
Vector{Symbol}
s,NTuple{N,Symbol}
orSet{Symbol}
. All the leaves of the flamegraph are calls tomake_oc_dict
, so @wsmoses could it be that we are not correctly caching theOpaqueClosure
s?I tried adding
@nospecializeinfer
,@noinline
andBase.inferencebarrier
to myTenet.contract
specialization forTracedRArray
s, but nothing.@reactant_overlay
seems to make it disappear from the profile, but compile time remains the same.It would be nice to have a better way to stop abstract interpretation at some points where we know that it's not worth it because we are already in a Reactant-specific method and we are just emitting MLIR ops, not tracing below.
CC @gbaraldi since I believe you're in charge of getting compile times down within the GB project.
The text was updated successfully, but these errors were encountered: