-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
De-duplicate edges in typeinfer
instead of gf.c
#58117
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
base: master
Are you sure you want to change the base?
Conversation
Since the caller CodeInstance is always part of the identity that we are de-duplicating on, this makes the linear scan much faster than it is in `gf.c`
} | ||
} | ||
} | ||
assert(!found && "duplicate back-edge registered"); | ||
#endif | ||
// reuse an already cached instance of this type, if possible | ||
// TODO: use jl_cache_type_(tt) like cache_method does, instead of this linear scan? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's worth seeing if we can bypass this remaining linear scan in the MethodTable edge insertion.
If I disable it manually, the timing drops to 440 milliseconds
…Table` These are restored in their entirety by staticdata.jl, so there's no need to serialize them. Dropping them has the additional advantage of making it unnecessary to de-duplicate edges in `gf.c`
On my system, this saves ~500 ms when loading CairoMakie (and all dependent packages)
72735ee
to
b8aa007
Compare
@@ -1997,6 +1997,9 @@ JL_DLLEXPORT void jl_method_instance_add_backedge(jl_method_instance_t *callee, | |||
jl_gc_wb(callee, backedges); | |||
} | |||
else { | |||
#ifndef JL_NDEBUG |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This introduces a race condition into the code (because of gc, threads, etc). Probably useful to know this scan is costly on some benchmarks though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you clarify where the race condition is?
Do you mean that inference may simultaneously try to store_backedges
for the same caller CI from two different threads?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see, we might be able to now assume that each CI is unique, while in older versions the MI were not expected to be unique
Without this PR, my system spends ~1.07 seconds just running
store_backedges
when doingusing CairoMakie
With this change, that drops to
0.641 seconds
That's still not fast enough for me, but we do call this function 236,092 times so maybe it's understandable.