On Thu, Jun 22, 2023 at 03:26:30PM +0200, Cayetano Santos wrote: > > > >mer. 21 juin 2023 at 22:39, Cayetano Santos wrote: > > >>mer. 21 juin 2023 at 16:36, Ludovic Courtès 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' I've been having a hard time with that command, so I've been running julia -e 'using Pkg; Pkg.add("BenchmarkTools"); using BenchmarkTools; N = 1000; A = rand(N, N); B = rand(N, N); @time A*B' I'm not sure if that's useful or not but I didn't see a different with LIBBLAS* set. > >> > >> 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. I'll see what comes with switching it to blas64 -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted