Hello! Julia’s great. Thanks to all who have made it happen. When I run
x=randn(5000,5000); eig(x);
on my Mac or on the Julia version compiled by me under Arch Linux, I see that all my cores get busy and I get the result reasonably quickly. When I run the same command on the Julia 0.6 installed as an Arch package or on the generic Julia 0.6 binary downloaded from julialang, only one core gets busy and it takes much longer to complete.
I’d like to report this to the Arch package manager, but was wondering if anybody here knows why this happens and how to fix it.
Thanks.
It appears that the Arch Julia package uses the reference Netlib BLAS, which is slow and single-threaded, instead of OpenBLAS. It would be a good idea to file an issue asking them to use OpenBLAS (including the version of LAPACK that OpenBLAS bundles and which is needed for multithreading support with some operations).
OTOH I wouldn’t have expected the generic binaries to use a single thread, but others will probably comment.
Consider using the openblas-lapack package from the Arch User Repository. One wonders why it’s not in the official repos.
Package maintainer says to install the AUR package openblas-lapack and Julia will use it instead. I’ve confirmed this. x=randn(2000,2000); @time eig(x); reported 38 seconds and used a single thread before I installed openblas-lapack and 11 seconds using four threads after.
1 Like
Proper integration with openblas will depend a rebuild of the Julia system image at the moment. Did installing openblas cause a 5-minute-or-so delay in rebuilding the Julia package?
No. It appeared to just work faster right away on my limited eig test.
Are there any simple tests that I can run to demonstrate to the package maintainer that simply substituting openblas for blas doesn’t work?
It’s really not great to have a slow Julia by default in Arch, requiring to manually install a package out of the main repo to make it fast. People are going to try the default setup and conclude that Julia is slow. Let’s hope they will move OpenBLAS to the main repo.
The parts that are unlikely to work immediately are the blas-vendor dependent functions, primarily changing the number of threads from the julia api.
I’ve submitted a feature request suggesting they promote openblas-lapack from “AUR” to “Community”, which woul then allow them to build julia using it.
3 Likes
Base.BLAS.set_num_threads() seems to work fine without any noticable rebuild of the Julia system image.
Are there any other features that may be degraded in BLAS or LAPACK if the Julia system image is not rebuilt when those libraries are swapped from, e.g. netbsd BLAS to openblas-lapack?
1 Like