I got the following error when I included the
ERROR: MethodError: no method matching comparetoref(; slowgcsleep=1.5)
Closest candidates are:
comparetoref(::DataFrames.DataFrame; refname) at C:\Users\Michael\.julia\packages\SystemBenchmark\deI1I\src\SystemBenchmark.jl:95 got unsupported keyword argument "slowgcsleep"
comparetoref() at C:\Users\Michael\.julia\packages\SystemBenchmark\deI1I\src\SystemBenchmark.jl:93 got unsupported keyword argument "slowgcsleep"
 top-level scope at none:1
And thanks to you for persevering with me!
My bad. Should be fixed now. Please retry above in a fresh session to pull the latest version
Tried it again but I still get the same exact error
I think you are better off by removing everything and start from a clean Julia installation (not Julia Pro) and start timing the Julia terminal.
That should be well less than 1 second, not 21 or even 16.
Then you can add packages and try VSCode or Juno/Atom… trying one at the time, you would see what is causing problems in your pc…
Yeah. Also, @Michael_Barmann feel free to join the julia slack and message me. I’m keen to make SystemBenchmark work for your setup… it’s designed to be for debugging this kind of thing!
On Win10 Julia 1.5.3 and experiencing the same problems as you.
PS: tried again 6 days later and it is now working fine. @ianshmean, thanks for the good stuff!
That SystemBenchmark PR needs work. I’ll post here once I’m more confident that it’s working.
Thanks, I’ll give that a shot.
Thanks! I just joined the Slack channel!
1/4/21 Update: Thanks to @ianshmean, I was able to successfully run comparetoref() from the SystemBenchmark package (github.com/ianshmean/SystemBenchmark.jl ) in Windows Powershell. This produced the following results:
julia> show(ans, allrows=true, allcols=true)
Row │ cat testname units ref_res test_res factor
│ String String String? Any Any Any
1 │ info SysBenchVer 0.3.0 0.3.4 Not Equal
2 │ info JuliaVer 1.4.1 1.5.3 Not Equal
3 │ info OS Linux (x86_64-pc-linux-gnu) Windows (x86_64-w64-mingw32) Not Equal
4 │ info CPU Intel(R) Core(TM) i7-9750H CPU @… Intel(R) Core(TM) i5-6200U CPU @… Not Equal
5 │ info WORD_SIZE 64 64 Equal
6 │ info LIBM libopenlibm libopenlibm Equal
7 │ info LLVM libLLVM-8.0.1 (ORCJIT, skylake) libLLVM-9.0.1 (ORCJIT, skylake) Not Equal
8 │ info GPU GeForce GTX 1650 with Max-Q Desi… missing Not Equal
9 │ cpu FloatMul ms 1.1339999999999999e-6 1.8e-6 1.5873
10 │ cpu FusedMulAdd ms 1.1339999999999999e-6 2.2e-6 1.94004
11 │ cpu FloatSin ms 4.051e-6 6.3e-6 1.55517
12 │ cpu VecMulBroad ms 2.9823115577889445e-5 6.1274e-5 2.05458
13 │ cpu CPUMatMul ms 0.018683 0.0961005 5.14374
14 │ cpu MatMulBroad ms 0.0042223 0.0276668 6.55255
15 │ cpu 3DMulBroad ms 0.0010529 0.0024499 2.32681
16 │ cpu peakflops flops 1.8061545733047305e11 5.6808e10 0.314524
17 │ cpu FFMPEGH264Write ms 107.751337 398.181 3.69537
18 │ mem DeepCopy ms 0.00018790257558790594 0.000274774 1.46232
19 │ mem Bandwidth10kB MiB/s 104871.77985698299 71383.4 0.680673
20 │ mem Bandwidth100kB MiB/s 58579.50346475738 35762.8 0.6105
21 │ mem Bandwidth1MB MiB/s 33439.963407070725 15608.4 0.466759
22 │ mem Bandwidth10MB MiB/s 5551.476774539766 6896.19 1.24223
23 │ mem Bandwidth100MB MiB/s 6910.9558841033295 5698.44 0.824552
24 │ diskio DiskWrite1KB ms 0.031895 7.4007 232.033
25 │ diskio DiskWrite1MB ms 0.920052 7.96815 8.66054
26 │ diskio DiskRead1KB ms 0.006683666666666667 0.187101 27.9938
27 │ diskio DiskRead1MB ms 0.143755 0.6543 4.55149
28 │ loading JuliaLoad ms 91.08045 268.197 2.94462
29 │ compilation compilecache ms 208.532099 633.895 3.0398
30 │ compilation success_create_expr_cache ms 235.4855485 683.357 2.90191
31 │ compilation create_expr_cache ms 0.894126 8.459 9.46064
32 │ compilation output-ji-substart ms 32.639706000000004 81.3901 2.49359
So based on the above table, DiskWrite1KB (row 24) is 232x slower on my system compared to the reference system. Unfortunately, we still don’t know what is causing this slowdown. Interestingly, DiskWrite1MB is “only” 8.66x slower, which seems to suggest that he slowdown may be due to some overhead cost with writing to the disk.
The above test was run with Windows Defender turned off (to test if this was slowing it down).
My computer info: ASUS ZenBook UX303UA 13.3-Inch FHD Touchscreen Laptop, Intel Core i5, 8 GB RAM, 256 GB SSD, Windows 10 (64 bit).
Any ideas or suggestions would be appreciated! (I’ve already tried uninstalling and reinstalling Julia, and running it with and without Julia Pro, but the results were pretty much the same.)
Did you choose where to install Julia? Is it in a default location?
I uninstalled Julia and reinstalled it to the default location, which was:
So it turns out that I had installed it in the default location originally…
I am at the moment out of ideas. I checked the system benchmark on my
Surface Pro which is pretty anemic thing: I use it only for reading papers.
It is much much faster than what you report. Do you have any other
system on which you could try it out?
I’ve created a table that should provide a better overview of the compile times (the first three time columns include compilation times, while the next three do not):
To summarize what I’ve tried so far:
- I uninstalled Julia Pro and reinstalled just Julia 1.5.3 and Atom/Juno and VSCode
SystemBenchmark with @ianshmean’s help and identified that DiskWrite1KB is 200x slower than the benchmark system, but couldn’t determine the cause of the slowness.
- Tried temporarily disabling Windows Defender and then rerunning
SystemBenchmark and rerunning the
@time using [package] commands, but the improvement was rather minimal (and not consistent).
- I’m curious to know how long
@time using DifferentialEquations and
@time using Plots; gr() takes for other people.
- Would the very slow writing to the disk, as identified by
SystemBenchmark, explain the slow compilation times?
- Does anyone know some probable causes of writing to the disk being slow? (As mentioned previously, writing
DiskWrite1MB was considerably less slow (8.66x the benchmark) compared to
DiskWrite1KB, suggesting that there is some large overhead cost that is creating a bottleneck. Any ideas for what the cause might be?
@time using DifferentialEquations I’m seeing about 5.3 seconds (on a relatively recent master). That said without precompilation I’m seeing closer to the 35 seconds you were.
@time using Plots; gr() clocks in at 2.3 seconds for me.
So the 5.3 seconds is from executing
@time using DifferentialEquations in a fresh session (but you had used
DifferentialEquations at least once before in a previous session)?
Yes, but this is much less of an issue in 1.6 and newer. 1.6 automatically precompiles when you add packages. Also, 1.6 has relatively negligible invalidation impact (for most packages), so there isn’t much difference between the first time you
using and any other time you include it in a fresh session.
Good to know, and I look forward to 1.6 coming out. But the table of times I reported in my last post does not include precompilation time. (Unless I am misunderstanding what precompilation means; I thought precompilation was what happens the very first time you use a package, i.e. not just the first time a package is compiled in a particular session.)