ALL NPPS Members

[Johannes Elmsheuser <johannes.elmsheuser AT cern.ch>]

!-------------------------------------------------------------------|
 This Message Is From an External Sender
 This message came from outside your organization.
|-------------------------------------------------------------------!

Hi Chris,

in ATLAS we have since a while dev3LCG Athena offline nightlies with 
gcc14 and gcc15 - dev3LCG means here that the current ROOT head version 
is used - the gcc15 nightly is in addition compiled with C++23 standard 
compared to the C++20 standard default with gcc14 - but we are not using 
any C++23 features yet - there are no other compilation optimizations 
used apart from the x86_64_v2 micro architecture by default. Our default 
gcc14 nightly uses ROOT 6.36/02 a few other "older" versions of some 
externals.

My unscientific quick test in running 3 times in a row a data22_13p6TeV 
RAW data reconstruction (8 threads) followed by a derivation production 
(8 processes) on 1100 events using these gcc14 and gcc15 nightlies 
showed that the gcc15 nightly on a 64 threads AMD EPYC 7302 bare metal 
machine is very slightly slower in the walltime for both workflows - our 
default gcc14 nightly is slightly faster than both of the dev3LCG 
nightlies. We have another special nightly which uses the x86_64_v3 
micro architecture compilation flag for the Athena stack (but not LCG or 
the OS), but we don't see any gains here so far.

I did not test a Geant4 workflow.

Side note: there is a claim that with EL10 that is compiled with 
x86_64_v3 micro architecture by default (so the full stack) there will 
be some performance gain of a few percent by default.

Cheers, Johannes

On 10/26/25 5:03 PM, pinkenburg wrote:
> Hi folks,
>
> I see claims that gcc 15 produces significantly faster binaries than gcc 
> 14 (in some cases 20%). Does anybody have experience how gcc 15 performs 
> with our use cases (event reconstruction, simulations)? I don't want to 
> go through this effort if there isn't a large enough carrot on the other 
> side.
>
> Thanks
> Chris