>mer. 21 juin 2023 at 22:39, Cayetano Santos <csant...@inventati.org> wrote: >>mer. 21 juin 2023 at 16:36, Ludovic Courtès <ludovic.cour...@inria.fr> wrote: > >> Hey! >> >> The benchmark you posted, Cayetano, is: >> >> julia -e 'using Pkg; Pkg.add("BenchmarkTools"); using BenchmarkTools; N = >> 1000; A = rand(N, N); B = rand(N, N); @btime $A*$B' >> >> This is a matrix multiplication that gets delegated to the underlying >> BLAS right. Running it under ‘perf record’ confirms it: >> >> Samples: 139K of event 'cycles:u', Event count (approx.): 99624880590 >> Overhead Command Shared Object Symbol >> 35.27% .julia-real libblas.so.3.9.0 [.] dgemm_ >> 3.99% .julia-real libjulia-internal.so.1.8 [.] gc_mark_loop >> 2.60% .julia-real libjulia-internal.so.1.8 [.] apply_cl >> 1.06% .julia-real libjulia-internal.so.1.8 [.] jl_get_binding_ >> >> We’re using libblas.so (presumably from the ‘lapack’ package) and not >> OpenBLAS, so no wonder it’s slow. >> >> Could it be that: >> >> "LIBBLAS=-lopenblas" >> "LIBBLASNAME=libopenblas" >> >> is ineffective? I think we have a lead! > > Are we following all instructions here ? > > > https://docs.julialang.org/en/v1.8/devdocs/build/distributing/#Notes-on-BLAS-and-LAPACK > > I’m thinking about the variables LIBLAPACK and LIBLAPACKNAME. To complete my previous comment, I just realised that Base.USE_BLAS64 gives "true" when running fast. Guix julia gives "false". C.
bug#63986: Julia is very slow
Cayetano Santos via Bug reports for GNU Guix Thu, 22 Jun 2023 06:28:37 -0700
- bug#63986: Julia is very slow Cayetano Santos via Bug reports for GNU Guix
- bug#63986: Julia is very... Ludovic Courtès
- bug#63986: Julia is ... Simon Tournier
- bug#63986: Julia... Ludovic Courtès
- bug#63986: J... Cayetano Santos via Bug reports for GNU Guix