On my MacBook Pro, I have encountered a number of kernel crashes while running the ‘solve’ command from the DifferentialEquations.jl package. One such situation occurs when I run the exact code from Example 3 here: Ordinary Differential Equations
I have tried with ‘vanilla’ Julia, with JuliaPro, with and without Jupyter, and these crashes happen in each case, any time there is a differential equation that’s not completely basic (I can run ‘Step 1’ from the link above, for example). Normally my terminal simply closes, or Jupyter informs me that the kernel crashed during code execution, but a couple of times the kernel did print an error to the screen, which included: “inline asm error. This value type register class is not natively supported”.
I’m currently running Julia 1.4, with DifferentialEquations 6.14. Any tips on what I’m doing wrong?
That should have been solved on the latest VectorizationBase, because it should now be querying LLVM for the supported instructions rather than checking the actual CPU.
Perhaps RecursiveFactorization should set a lower bound on this VectorizationBase version?
@perseid28 mind adding VectorizationBase, telling me the version it installed, and running solve again? Versions >= v0.12.7 should work.
Also, mind posting your full versioninfo() as well? I’m guessing you’re on a new MacBook with an Ice Lake CPU?
In case you’re curious about the problem: this CPU has a lot of new features, but because of how Apple does something, LLVM doesn’t recognize this and therefore cannot/will not use them. That bug should be fixed in Julia master, but VectorizationBase probably should have been checking with LLVM for features instead of CpuId anyway, so that’s what it started doing in v0.12.7.
I can make a PR. I’ll make it a later release to also add a check for if they aren’t using the usual LLVM (e.g., installed using Gentoo’s package manager). While I hope folks don’t do that, if it’s easy enough to support…
Thanks, that is good to know. I haven’t used Julia in a few months but this experience of it not “just working” was something new. In regards to your advice, I added VectorizationBase, v.0.12.12, but even after adding the package to my code I get the crash on the solve() call. Here’s my versioninfo():
Julia Version 1.4.2
Commit 44fa15b150* (2020-05-23 18:35 UTC)
Platform Info:
OS: macOS (x86_64-apple-darwin18.7.0)
CPU: Intel(R) Core(TM) i5-1038NG7 CPU @ 2.00GHz
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-8.0.1 (ORCJIT, goldmont)
We very recently updated to use these new vectorization tools since it gave some pretty massive accelerations on small stiff ODEs (<200) over OpenBLAS and MKL (without lots of tweaking). So it’s somewhat new, and it means we have to iron out a few things on a few CPUs, but the experience is so much better (10x faster small stiff ODEs than OpenBLAS for users who don’t manually change thread counts for example) that I want to just keep pushing this and fix any issues that come up, so thanks for reporting the issue because this is how the brave new world of performance will become stable.
please? By the way, it’s easier for others to read if you quote the output with triple-backticks ```, see Please read: make it easier to help you for more details.
It does work just fine on this build 1.6.0-DEV.306, without the VectorizationBase package. @Elrod mentions possible performance increases on the nightly build as well; I’m not sure how to check this, but if there’s something you want me to run just send me some code. Otherwise I’ll go ahead and remove this build, since 1.4 has been sorted.
I don’t remember what I imported last time, but here I’m only using DifferentialEquations and BenchmarkTools. I ran updates just prior, so both 1.4 and 1.6 are running VectorizationBase 0.12.16.
Interesting. Mind showing the @code_native debuginfo=:none and/or the @code_llvm debuginfo=:none of both?
The fact that sum didn’t improve suggests it is still just using ymm registers on Julia 1.6.
Then, mind also showing this for both versions: VectorizationBase.REGISTER_COUNT and VectorizationBase.REGISTER_SIZE? VectorizationBase.REGISTER_SIZE is now obviously in agreement with LLVM (if it isn’t, you’ll get crashes), but I’m worried about REGISTER_COUNT. Depending on those results, I’ll have something else for you to run to see if that is wrong.
If it is wrong, code will run, but much more slowly.
So that is a possible explanation for the performance degradation, which is why I want to look into it.
