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