`JULIA_CPU_TARGET` is ordered-dependent when compiling with `juliac`

[Moelf]

https://github.com/Moelf/FHist.jl/blob/C_FHist/C_FHist/

julia> versioninfo()
Julia Version 1.13.0-DEV.834
Commit c3282ceaacb (2025-07-08 07:05 UTC)
Build Info:
  Official https://julialang.org release
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 24 × AMD Ryzen 9 3900X 12-Core Processor
  WORD_SIZE: 64
  LLVM: libLLVM-20.1.2 (ORCJIT, znver2)
  GC: Built with stock GC

>julia +nightly --project=.. ~/.julia/juliaup/julia-nightly/share/julia/juliac/juliac.jl --output-lib libfhistjl.so --compile-ccallable --experimental --trim C_FHist.jl

JULIA_CPU_TARGET='znver2;generic' julia +nightly

=====================================
Input size: 100000
All close: True
Numpy    time (ms): 1.2849700055085123
FHist.jl time (ms): 0.12393159558996558
=====================================
Input size: 1000000
All close: True
Numpy    time (ms): 6.515748403035104
FHist.jl time (ms): 1.4926746021956205

JULIA_CPU_TARGET='generic;znver2' julia +nightly

=====================================
Input size: 100000
All close: True
Numpy    time (ms): 1.3016978045925498
FHist.jl time (ms): 0.24966440396383405
=====================================
Input size: 1000000
All close: True
Numpy    time (ms): 6.477032997645438
FHist.jl time (ms): 2.470186399295926

[JeffBezanson]

Are the results different in the REPL, i.e. without juliac or trimming?

[giordano]

I haven't tried the example above, but #54471 fixed a very similar-looking issue for regular pkgimages.

[Moelf]

with REPL, I can't even tell the difference between generic and znver2 for some reason:

akako@archlinux ~/.j/d/F/C_FHist (C_FHist)> JULIA_CPU_TARGET='generic' julia +nightly -q --startup-file no --project=..
A new `nightly` version is available. Install with `juliaup update`.
julia> using BenchmarkTools, FHist

julia> const a = rand(1000000);

julia> @benchmark Hist1D($a; binedges=0:0.05:1)
BenchmarkTools.Trial: 2800 samples with 1 evaluation per sample.
 Range (min … max):  1.286 ms …   2.603 ms  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     1.773 ms               ┊ GC (median):    0.00%
 Time  (mean ± σ):   1.781 ms ± 185.898 μs  ┊ GC (mean ± σ):  0.00% ± 0.00%

                  ▂▂▂▅▅▅▆▅▆▄▄▆▆▆▅▇▇█▄▄▃▄▂▃▃▂ ▁
  ▂▂▂▃▁▃▂▃▄▃▄▆▆▇▇█████████████████████████████▇▇▇▆▇▆▅▄▄▃▄▄▃▃▃ ▆
  1.29 ms         Histogram: frequency by time        2.24 ms <

 Memory estimate: 720 bytes, allocs estimate: 10.

akako@archlinux ~/.j/d/F/C_FHist (C_FHist)> JULIA_CPU_TARGET='znver2;generic' julia +nightly -q --startup-file no --project=..
A new `nightly` version is available. Install with `juliaup update`.
julia> using BenchmarkTools, FHist

julia> const a = rand(1000000);

julia> @benchmark Hist1D($a; binedges=0:0.05:1)
BenchmarkTools.Trial: 2818 samples with 1 evaluation per sample.
 Range (min … max):  1.235 ms …   2.532 ms  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     1.759 ms               ┊ GC (median):    0.00%
 Time  (mean ± σ):   1.770 ms ± 180.100 μs  ┊ GC (mean ± σ):  0.00% ± 0.00%

                     ▂▂▂▁▄▆▇▅▄▆█▆▄▆▆▅▄▄▂▄▁
  ▂▁▂▂▂▂▂▃▄▃▃▄▄▅▅▆████████████████████████▇██▇▆▅▆▅▄▄▄▃▃▃▃▃▃▃▃ ▅
  1.24 ms         Histogram: frequency by time        2.26 ms <

 Memory estimate: 720 bytes, allocs estimate: 10.

[Moelf]

actually, the time makes no sense when compare to Python's results, I think the unit might be wrong

The timing at the top of the post should all be in ms and I wonder if I'm seeing effect of Python GC at play here.

But the JULIA_CPU_TARGET dependent behavior is reproducible

[JeffBezanson]

OK I am curious about the difference in instruction mix between the two binaries. Please try installing the BinaryBuilder package with julia 1.7 (!!) and run the following:

foreach(println, BinaryBuilder.Auditor.instruction_mnemonics("lib.so", Platform("x86_64", "linux"))[2])

That will tell us how much each instruction set extension is used in the two cases.

[Moelf]

@JeffBezanson didn't even know that exists! Here's the results:

julia> foreach(println, BinaryBuilder.Auditor.instruction_mnemonics("libfhistjl_generic_znver2.so", Platform("x86_64", "linux"))[2])
"sse2" => 593
"bmi2" => 79
"rdseed" => 0
"avx512vex" => 0
"aes" => 0
"xsavec" => 0
"sse4" => 0
"rdwrfsgs" => 0
"avx2" => 9
"fma" => 1
"avx512evex" => 0
"f16c" => 0
"movbe" => 0
"pku" => 0
"mmx" => 1714
"ssse3" => 0
"xsaves" => 0
"pclmulqdq" => 0
"cpuid" => 0
"clflush" => 0
"avx" => 1235
"clwb" => 0
"unknown" => 88531
"sse3" => 0
"sse" => 927
"bmi1" => 88
"adcx" => 0

julia> foreach(println, BinaryBuilder.Auditor.instruction_mnemonics("libfhistjl_znver2_generic.so", Platform("x86_64", "linux"))[2])

"sse2" => 415
"bmi2" => 102
"rdseed" => 0
"avx512vex" => 0
"aes" => 0
"xsavec" => 0
"sse4" => 6
"rdwrfsgs" => 0
"avx2" => 11
"fma" => 1
"avx512evex" => 0
"f16c" => 0
"movbe" => 0
"pku" => 0
"mmx" => 1671
"ssse3" => 0
"xsaves" => 0
"pclmulqdq" => 0
"cpuid" => 0
"clflush" => 0
"avx" => 1825
"clwb" => 0
"unknown" => 88448
"sse3" => 0
"sse" => 610
"bmi1" => 93
"adcx" => 0

[JeffBezanson]

Actually I think this is expected behavior. The first target listed is a base target; we will compile everything for that and only clone functions for later targets based on some heuristics. generic;znver2,clone_all would force cloning everything. But it also seems our heuristics might be making bad decisions here, which I'm curious about.

[Moelf]

generic;znver2,clone_all

the problem for juliac is that this does not work -- the program would crash without any error upon dynamically calling a symbol from .so

[JeffBezanson]

Does removing --trim fix the crash?

[Moelf]

without --trim it still crashes without any message (exit code 1)