Asm code selection made hard
hermann at stamm-wilbrandt.de
hermann at stamm-wilbrandt.de
Sat Sep 5 22:37:34 CEST 2026
On 2026-09-05 15:55, Torbjörn Granlund wrote:
> When new CPUs come out, it usually takes more than a year before we get
> CPU access, find time to optimize for that CPU, and make a GMP release.
>
> Currently, we're lagging behing several X86 CPU generations.
>
You could add a list of missing CPUs on https://gmplib.org/, then wait
for people
having access to those to run tests (multiple times) for you.
For example AMD 9950X CPU GAed less than 13 months ago and I own one.
I own older Xeon CPUs (without the P+E mess) that might be needed as
well
because they are not so common (like 8-socket Xeon E7-8890 v4 CPU).
I had a similar problem when I wanted to benchmark gwnum lib performance
on differnt CPUs.
I created thread "Please help with a few minutes of your CPU time for
gwnum lib comparison"
https://www.mersenneforum.org/node/1060961
22 months ago, and over time many people provided benchmark runs, and
now table
has 35 different CPUs listed (for viewing without a mersenneforum.org
login):
https://stamm-wilbrandt.de/images/gwnum_lib_comparison.png
> 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
>
> 2. choose some compromise code vectors which runs sub-optimally on both
> P and E cores.
>
> We could also allow for core names like "skymont" and "lioncove" and
> let interested users use command like tasksel to run the optimal code
> on
> each core type. I suppose this is fairly straightforward.
> ...
>
On mersenneforum.org there are people running factoring and/or prime
proving software
only on the P cores because the E cores do not help much. So perhaps
option 1?
Regards,
Hermann.
More information about the gmp-devel
mailing list