Closed WPettersson closed 6 months ago
I've done some searching and found pre-compiling tutorials for Julia which may be of use for this package - https://julialang.org/blog/2021/01/precompile_tutorial/ - which may be useful for KidneyExchange.jl. For now, I think I'll just move forward with the slow approach of solving a simple instance before the instance which I wish to have timed.
If you use the following line, you can see why
@time bp_status, graph_info, subgraph_info = solve_with_BP(filename, cycle_limit, chain_limit, bp_params, timer, max_time);
4.452510 seconds (3.35 M allocations: 226.498 MiB, 1.72% gc time, 99.53% compilation time: 4% of which was recompilation)
@time bp_status, graph_info, subgraph_info = solve_with_BP(filename, cycle_limit, chain_limit, bp_params, timer, max_time);
0.010202 seconds (11.83 k allocations: 516.062 KiB)
I think it is a good practice to solve a small case to warm-up . I will try to dive into https://julialang.github.io/PrecompileTools.jl/stable
I come back here and after thoughts, if you solve a small case before it won't change anything because the compilation time does not depend on the problem size.
You create an image with the package using the way explained in this short video https://www.youtube.com/watch?app=desktop&v=_3vJSBk0Bls
I will add the procedure in the documentation.
Dear @WPettersson I had the doc to create a sysimage with PackageCompiler to speed-up the computation
https://jeremyomer.github.io/KidneyExchange.jl/dev/sys_image/
I'm running some benchmarks of my own, and I found an oddity when using the KEPTestBP.jl file, or indeed just calling
solve_with_BP()
.If I start a julia session to just solve the 00036-00000001 using KEPTestBP.jl with a cycle length of 3 and a chain length of 2, I get told that on my system this takes 4.04s total, with 1.7s spent in Process_Node.
Output when solving just 00036-00000001
However, if I create KEPTestBP-repeat.jl which just duplicates the call to
solve_with_BP()
(just a snippet of the file)
and then run this file and look at only the timing detail for the second run, I now see a total of 3.75ms with only 841μs spent in Process_Node. Somehow this second run is significantly faster. Further testing has shown that it's always the first run that is slow, and all future runs are much faster across. I've also tested this on two different computers in case that might cause issues.
I decided to see what happens if I solve two different instances, is the second instance also fast or slow? For this, I also downloaded the instance 00036-00000002 from PrefLib, and used the following
(just a snippet of the file)
The idea here was to solve instance 00036-00000002 to "warm up" (not warm-start in the MIP sense) and see how long the 00036-00000001 instance took to solve. As it turns out, even in this scenario the 00036-00000001 instance only took ~4ms to solve (see below), while the 00036-00000002 instance took around 4 seconds.
At first I suspected perhaps timers weren't properly reset, but I can also confirm from simply watching my terminal output that it does really seem like the first instance to be solved does take a lot longer, and that the second one is blazingly fast, which makes me wonder whether there's some caching that Julia does that isn't being taken into account. However, I'm no Julia expert (this is the first piece of Julia code I've ever used) so I wanted to check to see if there's anything obvious I'm missing.