USE_INTEL_MKL and USE_INTEL_LIBM doesn't seem to have any effect anymore?

[carstenbauer]

Compiling the current master with USE_INTEL_MKL = 1 and USE_INTEL_LIBM = 1 in the Make.user doesn't seem to have any effect for me (on a linux HPC cluster).

Compilation runs through smoothly without any relevant warnings / errors and the produced binary runs just fine as well. However, it is still using libopenlibm and libopenblas64_.so:

julia> versioninfo()
Julia Version 1.8.0-DEV.128
Commit 5faad5fee9* (2021-07-04 21:16 UTC)
Platform Info:
  OS: Linux (x86_64-suse-linux)
  CPU: Intel(R) Xeon(R) Gold 6148 CPU @ 2.40GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-12.0.0 (ORCJIT, skylake-avx512)
julia> using LinearAlgebra; BLAS.get_config()
LinearAlgebra.BLAS.LBTConfig
Libraries:
└ [ILP64] libopenblas64_.so

Any idea what's going on here? Seems like a bug to me.

(I know about MKL.jl but it currently doesn't have an option to use the system-wide MKL installation instead of MKL_jll.jl. Also it doesn't switch out LIBM.)

[ViralBShah]

I'm pretty sure that with the migration to LBT, we no longer support these options. We have MKL.jl for MKL (where you opened an issue to use your cluster's MKL). For libm, we pretty much are native Julia now, and USE_INTEL_LIBM doesn't do much at all.

If we mention these things in the build docs somewhere, we need to update them.

[ViralBShah]

For people who do want to use other libms (I imagine faster log and exp), some work would be necessary in setting it all up in Base in a more modern way.

[carstenbauer]

Yes, given that we can make MKL.jl use a system-wide MKL I agree that USE_INTEL_MKL is redundant. However, that we seem to have lost the option to use a faster LIBM is a bit unfortunate. When I compared OpenBLAS vs Intel LIBM in 2018 the difference was about a factor of 2 (see https://discourse.julialang.org/t/use-intel-libm-1/16817/2). Of course, I hope that we will just have fast, native Julia implementations but we aren't there yet, are we?

[carstenbauer]

If we mention these things in the build docs somewhere, we need to update them.

Yes, the build docs should certainly be updated.

[DilumAluthge]

If we mention these things in the build docs somewhere, we need to update them.

Yes, the build docs should certainly be updated.

#41474

[simeonschaub]

When I compared OpenBLAS vs Intel LIBM in 2018 the difference was about a factor of 2 (see https://discourse.julialang.org/t/use-intel-libm-1/16817/2). Of course, I hope that we will just have fast, native Julia implementations but we aren't there yet, are we?

sinh at least should be all native Julia now: #37426

[carstenbauer]

That's great!

The thing is, though, that

1. I can't compare the current implementations to Intel LIBM anymore (at least not in Julia).
2. It seems that the USE_INTEL_LIBM feature has been dropped rather unconsciously / without consideration (please correct me if I'm wrong). So it's unclear to me which LIBM functions are pure Julia and which call into OpenBLAS's LIBM. (And if the latter, I can hardly do anything about it.)

I would have liked a more systematic comparison (w.r.t. feature completeness and speed) of the "Julia LIBM" and e.g. Intel LIBM before dropping USE_INTEL_LIBM. But we are where we are now and I guess that's life 😄

[carstenbauer]

Alright, since we seem to be close to a pure-Julia LIBM [1,2] and for MKL we have MKL.jl - potentially with the option to use an Overrides.toml to use a system-wide installation - I'm going to close this.

[1] https://twitter.com/Viral_B_Shah/status/1367241342670299142

[2]

% grep -r "call.*libm\b" base 
base/math.jl:    ccall((:remainder, libm),Float64,(Float64,Float64),x,y)
base/math.jl:    ccall((:remainderf, libm),Float32,(Float32,Float32),x,y)
base/math.jl:    f = ccall((:modff, libm), Float32, (Float32, Ptr{Float32}), x, temp)
base/math.jl:    f = ccall((:modf, libm), Float64, (Float64, Ptr{Float64}), x, temp)