-
-
Notifications
You must be signed in to change notification settings - Fork 12
Interpret? #19
Comments
I'd say we might as well make it the default for this package, i.e. have the higher level function call |
Cool idea @shashi! Doing this would put extra pressure on the interpreter (correctness-wise & performance-wise), which is probably a good thing. CCing @KristofferC. Memory consumption is going to be high with the interpreter, if for no reason other than nothing is inferrable so everything get boxed. There are a couple of lines I'm a bit surprised about, but most of that looks utterly unavoidable with the current design. Speaking purely of performance, unless there have been regressions we appear to be pretty near a local optimum now, but a more radical change could conceivable improve matters quite a bit. My favorite is JuliaDebug/JuliaInterpreter.jl#309 but that will require someone (me?) carving out a month or so. |
Also worth pointing out that your memory consumption analysis appears to include initialization of the module. ( |
Is the memory consumption here including the compilation of the first call to Also, why are we profiling memory instead of time? :) |
@timholy Thanks for looking at this! Good to know it's a local minima already :) I don't understand what's happening your serialization PR yet, but it sounds good! @KristofferC Haha I was profiling with julia> @time @interpret sparsity!((y,x)->y[1:2] .= x[2:end], [1,2,3], [1,2,3])
Explored path: SparsityDetection.Path(Bool[], 1)
12.001681 seconds (25.35 M allocations: 1.281 GiB, 3.33% gc time)
3×3 SparseArrays.SparseMatrixCSC{Bool,Int64} with 2 stored entries:
[1, 2] = 1
[2, 3] = 1 1.28G (second run) is a lot.
Yes, I did it again for the second run only:
|
That's how it is. To avoid 265-like behavior, the interpreter clears all its old FrameCodes after each exit. So all those lines in |
JuliaInterpreter could speed up this package in theory. We usually need to run it once, and the compilation is garbage anyway.
A simple problem such as
Takes 7 seconds. Which is 2x faster than compiled first run.
I did a track-allocation run and below are the worst offending lines. 3rd column is the byte count. (1st is line number). If anyone in JuliaInterpreter is interested in looking into this together or would suggest something, that would be awesome! cc @timholy
The text was updated successfully, but these errors were encountered: