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