Asm code selection made hard

Niels Möller nisse at lysator.liu.se
Sun Sep 6 11:47:51 CEST 2026


Torbjörn Granlund <tg at gmplib.org> writes:

> A new problem has emerged for Intel CPUs.  Most of them come with
> performance, or "P" cores and efficiency, or "E".  For example, an
> "Intel Core Ultra 5 235" has "Lion Cove" performance cores and "Skymont"
> efficiency cores.  To my surprise, these cores have VERY different
> characteristics.

How are these cores typically allocated to processes/threads? I would
guess that a heavily crunching single-threaded GMP-application would be
scheduled on a P-core, while a highly multithreaded GMP-application
would use available P cores and a bunch of E cores too?

Is it possible for an application (e.g., in GMP's fat setup code) to pin
"this process should be scheduled exclusively on P cores"?

> I am at loss what to do in GMP.  Should we,
>
> 1. choose the mpn code vectors as if the E cores don't exist (and then
> get perhaps 2x extra performance penalty there, in addition to their
> lower frequency), or

Kind-of makes sense. When performance matters, it becomes the
responsibility of operating system or user to ensure that the code gets
scheduled on a P core. But would be unfriendly in the heavily
multithreaded case.

> 2. choose some compromise code vectors which runs sub-optimally on both
> P and E cores.

This makes some sense too, in particular if there's some way to
override. Something like export GMP_FAT_OVERRIDE=I_WANT_CODE_FOR_P_CORE.

> My next question is: How about fat builds?  :-)

A user option to force fat setup to prefer code tailored for the P or E
cores of the current cpu would be nice. Could also explore ways to pin
the process to one type of core, if that is at all possible.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.


More information about the gmp-devel mailing list