Benchmarking with and without multithreading (AMD's SMT) on a HPC

Tooling Profiling
1

Hello, I’m having a HPC access with a multithreading enabled but if I look at other users’ job submissions/ allocation info, I often see no one requests these multithreading in AMD EPYC CPUs explicitly.

I’m trying to benchmarks and see it for myself, is there any package that plays well with Threads.nthreads that might be suitable for this study.

I’m familar with OrdinaryDiffEq.jl , DynamicalSystems.jl but do these use threads as well?

I’m thinking there might a package already to do this kind of study like as threads increase how the performance get affected. With slurm I can restrict the way it allots cpus/threads.

Any pointers are much helpful thanks.

2

I’m thinking something like Parallel Monte Carlo · OhMyThreads.jl

3

It happens that I’m currently having access to a EPYC machine:

julia> versioninfo()
Julia Version 1.12.7
Commit 6d172b025e4 (2026-08-15 08:05 UTC)
Build Info:
  Official https://julialang.org release
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 256 × AMD EPYC 7763 64-Core Processor
  WORD_SIZE: 64
  LLVM: libLLVM-18.1.7 (ORCJIT, znver3)
  GC: Built with stock GC
Threads: 255 default, 1 interactive, 255 GC (on 256 virtual cores)

, and I happen to have some experience solving practical engineering problems using Julia’s multi-threading APIs.

Although I’m not familiar with those two packages mentioned in the #1 post, I think it’s not a drawback merely because they don’t make use of multithreading. A main feature of Julia is its composablility, so we can carry out our own multithreaded implementations with the auxiliary APIs provided by 3rd-party packages running in single-threaded mode. It should be more flexible.

On my machine I have 2 physical CPUs, each having 64 physical cores. So it’s a total of 128 physical cores. I guess you probably want to understand

  • if julia --threads=255,1 woule be better than julia --threads=127,1

, as you mentioned AMD’s SMT in your title. Well, I’m also a bit curious about this difference. But I don’t think they should vary too much in terms of overall performance in my real engineering problems.

Currently I only have experience using multithreading in a single computer, so I can’t say anything if multiple computers are available. But I think in that circumstance, the code needs to be rewritten to attain maximum performance. And more importantly I think not all real-world problems can be perfectly parallelized (like the one I worked with, in which it has an inherent sequential-programming bottleneck subprocedure). So I think the responsibility is at the user’s side, if efficiency is really wanted.

4

I guess you probably want to understand

  • if julia --threads=255,1 woule be better than julia --threads=127,1

Affirmative! that’s the case I want to understand.

What made me curious was, Slurm doesn’t allot non-physical cpus to a distinct jobs. As a result of that in HPC above, if you are requesting 128 CPUs you automatically get 256. It’s up to the user to decide either they make use of multithread or not.

Currently I only have experience using multithreading in a single computer, so I can’t say anything if multiple computers are available

I’m also on the same page here, right now I’m trying to understand the difference with just one node in question.

A single node is configured similarly to yours (2 sockets, 64 cores, 2 threads), These are the info,

julia> versioninfo()

Julia Version 1.12.7
Commit 6d172b025e4 (2026-08-15 08:05 UTC)
Build Info:
  Official https://julialang.org release
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 256 × AMD EPYC 9554 64-Core Processor
  WORD_SIZE: 64
  LLVM: libLLVM-18.1.7 (ORCJIT, znver4)
  GC: Built with stock GC
Threads: 256 default, 1 interactive, 256 GC (on 256 virtual cores)