Asm code selection made hard

[Torbjörn Granlund]

Niels Möller <nisse at lysator.liu.se> writes:

  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?

That's my understanding.

One of the GMP test systems, a Core i5 12600K Alder Lake 6P + 4E cores,
runs a single CPU bound processes primarily on an E cores.  That's not
what I had expected, and I only now discovered that (I have had the E
cores disabled until recently).  If I start more than one CPU bound
process, both run on a P core until the first one terminates.  Wild.

Some more experiments:

  ald$ for i in $(seq 1 1); do time ./a.out & done 2>&1 | grep user
  user    0m3.916s
  ald$ for i in $(seq 1 2); do time ./a.out & done 2>&1 | grep user
  user    0m0.410s
  user    0m3.915s
  ald$ for i in $(seq 1 3); do time ./a.out & done 2>&1 | grep user
  user    0m0.253s
  user    0m0.356s
  user    0m1.849s
  ald$ for i in $(seq 1 4); do time ./a.out & done 2>&1 | grep user
  user    0m0.216s
  user    0m0.250s
  user    0m0.445s
  user    0m2.114s

Forcing things to an E core:

  ald$ time taskset -c 15 ./a.out
  user    0m3.915s

Forcing things to a P core:

  ald$ time taskset -c 0 ./a.out
  user    0m0.209s

I assume this is some Linux idiosyncrasy.  A newer heterogeneous system,
a "Core Ultra 5 235", does not exhibit a similar weird behaviour.

  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"?

Yes, there is a command-line tool, taskset, which allows for that even
for a mere luser like myself.  I am not familiar with the underlying
kernel interface.  E.g., can you ask for a set of cores or do you have
to ask for a specific core number?  (In the latter case, this seems
pretty useless.)

  > 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.

Thanks for the feedback!

-- 
Torbjörn
Please encrypt, key id 0xC8601622