Add some precompiles #201
Add some precompiles #201
Conversation
On the current release, the first call looks like this: ```julia julia> @time imfilter(img, KernelFactors.gaussian((3,3))); 2.135609 seconds (3.46 M allocations: 211.109 MiB, 12.01% gc time, 94.98% compilation time) julia> @time mapwindow(extrema, img, (3,3)) 0.756083 seconds (1.17 M allocations: 68.258 MiB, 6.57% gc time, 99.89% compilation time) ``` On this branch, it looks like this: ```julia julia> @time imfilter(img, KernelFactors.gaussian((3,3))); 0.620004 seconds (362.78 k allocations: 40.455 MiB, 1.47% gc time, 96.09% compilation time) julia> @time mapwindow(extrema, img, (3,3)) 0.385470 seconds (334.52 k allocations: 19.585 MiB, 9.43% gc time, 99.82% compilation time) ``` Quite a nice reduction in latency.
Codecov Report
@@ Coverage Diff @@
## master #201 +/- ##
==========================================
- Coverage 91.59% 91.00% -0.59%
==========================================
Files 9 10 +1
Lines 1380 1412 +32
==========================================
+ Hits 1264 1285 +21
- Misses 116 127 +11
Continue to review full report at Codecov.
|
| function mapwindow(f::F, img, window; border="replicate", | ||
| indices=default_imginds(img, window, border), callmode=:copy!) where F |
There was a problem hiding this comment.
So f::F where F is more friendly to precompilation than f::Any?
There was a problem hiding this comment.
As you may know, it forces specialization on f; while Julia typically specializes for each argument type, potentially unlimited "abstract" types like Function, Type, and Tuple have heuristics that cause Julia to sometimes choose to compile a generic version rather than a specific one. Historically the main reason to force specialization was better runtime performance, at the cost of increased latency (because you have to do more compilation for each specialization). However, loss of specialization means loss of backedges and thus precompilability, so its a bit of a tradeoff.
It might be worth experimenting here a bit more before merging this, just to see if we can get the same benefit by other means. I didn't poke at this point extensively, I just noticed an inference failure due to lack of specialization. But the main reason I changed it is that mapwindow is pretty performance-sensitive, and it makes sense that at least mapwindow_kernel should be specialized on f. This PR doesn't technically guarantee that, though it seems the current heuristics must be making that happen anyway given the changes here. Like I said, probably worth poking a bit more before we merge this. I've got a few other priorities first (I did this as part of testing out major changes to SnoopCompile, and I want to get that done before coming back to this).
|
I think we can merge this as-is, and continue in separate efforts. |
On the current release, the first call looks like this:
On this branch, it looks like this:
Quite a nice reduction in latency.
I should note this requires JuliaMath/AbstractFFTs.jl#48 and also some changes to FFTW.jl that I haven't yet submitted since they rely on the changes in AbstractFFTs.