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