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
#41 introduced the idea of using Compiled mode to finish tests (or preparatory steps) that take too long, so that an Abort doesn't nix later tests depending on the results. However, the implementation has several deficiencies:
it starts again from the beginning of the highest-level statement; instead, it should start at the lowest level on the stack and work its way back up. That will prevent it from repeating work (which is what it does now).
in some cases it may not fix the performance problem: it still has to interpret the frame that threw the Abort. Compiled means it won't need to recurse anymore, but if that frame happens to have an insanely long loop you'll still be stuck for a long time.
What we need instead is the notion of a compiled "resumer" function: starting from the method body, build a (temporary) function that schematically looks like this (would be built from lowered expressions in reality):
function#foo_resumer#34(slotvalues...)$(slotname[1]) = slotvalues[1]
...$(slotname[n]) = slotvalues[n]
goto pc_where_it_quit
$body
end
Then this could be called, in which case it would finish the computations in a truly compiled mode.
It has not escaped my attention that together with evaluate_limited!, this implements a possible means of addressing Julia's compiler-latency problems. Once this last piece is in place, I believe it would be a complete implementation of "interpret by default, then fall back gracefully to compiled mode for 'hot' portions of the code."
The text was updated successfully, but these errors were encountered:
#41 introduced the idea of using
Compiled
mode to finish tests (or preparatory steps) that take too long, so that anAbort
doesn't nix later tests depending on the results. However, the implementation has several deficiencies:Abort
.Compiled
means it won't need to recurse anymore, but if that frame happens to have an insanely long loop you'll still be stuck for a long time.What we need instead is the notion of a compiled "resumer" function: starting from the method
body
, build a (temporary) function that schematically looks like this (would be built from lowered expressions in reality):Then this could be called, in which case it would finish the computations in a truly compiled mode.
It has not escaped my attention that together with
evaluate_limited!
, this implements a possible means of addressing Julia's compiler-latency problems. Once this last piece is in place, I believe it would be a complete implementation of "interpret by default, then fall back gracefully to compiled mode for 'hot' portions of the code."The text was updated successfully, but these errors were encountered: