Asm code selection made hard

Richard Biener rguenther at suse.de
Tue Oct 6 09:08:13 CEST 2026


On Sat, 5 Sep 2026, Torbjörn Granlund wrote:

> An example of cycle counts for mul_basecase for two 50-limb operands:
> 
>       alder    bd1     bt1    core2   has-     broad-  sandy    k8     zen
>       lake                            well     well    bridge
> 
>   E    5.41    1.51    2.58    1.55    3.06    1.36    1.34    2.09    2.09
>   P    0.97    1.11    1.33    1.16    1.03    1.20    1.26    1.30    1.32
> 
> 
> The code developed for Intel's Alder Lake's E cores, runs well on the
> Lion Cove cores at less than 1 cycle/limb.  All code variabts run
> decently on the P cores.
> 
> But the E cores are much less robust, with results varying from 1.34 to
> more than 5 cycles/limb.
> 
> And here is the crux: the code that is the fastest for the P cores is
> the slowest for the E cores.

The recommendation would be to tune to the P cores which is where
performance applications are supposed to be scheduled to by the
operating system.  Of course that breaks down for threaded workloads
that expect maximum throughput - for that case a "blend" approach
might work best, from the above set I'd chose the bd1 variant,
prioritizing single-thread performance at the least cost for the
maximum throughput case.

I don't think there's any change for fat vs. non-fat builds, only
non-fat builds which are not targeted for the system gmp is built
on (aka, not -march=native) might warrant a statically configured
"best blend" over "current" architectures (much like GCCs
-mtune=generic is a "moving target" across versions).

For fat builds there'd be the opportunity to periodically
"re-sample" in case a process gets re-scheduled - note I don't
know off-head if there's a simple documented way to query if
you are running on a P core, an E core or a LP-E core (yes! there's
now three kinds of cores!), and the core selected at process
startup is very likely not the one that's active when running into
GMP code ...

Richard.

-- 
Richard Biener <rguenther at suse.de>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Stefan Gaiser, Jochen Jaser, Abhinav Puri; (HRB 36809, AG Nuernberg)


More information about the gmp-devel mailing list