GMPbench results. We have run the benchmark on the highest-frequency CPU of each type to which we have convenient access. Scaling to lower or higher frequencies should work well, since GMP mainly works off the caches. All CPUs run at their nominal frequencies; "turbo" has been disabled.

The GMPbench suite is available for download. To run the benchmarks, you also need to compile gexpr.c and put it somewhere in your path.

GMP exercises a particular set of processor capabilities, widening integer multiplication being the most important one. Processors with poor integer multiply support get worse scores on GMPbench than on other benchmarks.

GMPbench measures multiplication of same size and different size operands, squaring, division, gcd, and extended gcd, and then RSA encryption and π computation. That's it. GMP typically performs a whole lot more operations which are not measured at all.

Let us make it absolutely clear that GMP exercises just integer instructions, and that GMPbench thus is an integer benchmark. We often see claims to the contrary, i.e. that it is a floating-point benchmark.

GMPbench is a single-threaded benchmark. Most CPUs below can execute multiple threads in parallel using some separate and some shared hardware resources. Most operations in GMP up to quite large operand sizes would scale very well over multi-core systems, but poorly with SMT. A hypothetical multi-threaded GMPbench would therefore give about 8 times the current Ryzen 2700X score but only about 4 times the current Xeon E3-1270v5 score.

GMP repo [measured at different times, therefore unfair] GMPbench 0.2 results

Table Footnotes

1. Measurements were performed on an idle system with automated hardware up-clocking ("Turbo") enabled.
2. Our Ryzen 2700X system reports frequent parity errors from its UOP cache. It is unknown what effects these CPU hardware errors have on the CPU's operation. There are many reports on the Net about this issue, so it's very likely a CPU bug. Furthermore, the system freezes reproducibly during GMP test runs; it happens when the load goes from high to low and the CPU up-clocks itself. Performance results should be taken with a grain of salt.
3. These results are without or with incomplete Meltdown or Spectre mitigations. Results published here are probably somewhat inflated.
4. These results are without or with incomplete Spectre mitigations. Results published here are probably somewhat inflated.

GMP 5.0.1 GMPbench 0.2 results

GMP 4.3.x GMPbench 0.2 results

1. The last column, "Possible Score/GHz", is an estimate of what could be attained by implementing known optimisations to GMP for this processor.

GMP 4.3.x GMPbench 0.1 results

1. The clock frequencies for the above measures are not the same as for GMP 4.2, since we didn't have access to the same hardware. However, we have remeasured some of the 4.2 numbers and updated the table below.
2. The last column, "Optimal", is an estimate of what could be attained by writing optimised assembly code for this processor.

GMP 4.2.x GMPbench 0.1 results

GMP 4.1.x results

• There was no assembly loop support for Opteron/Athlon64 in GMP 4.1.4. We therefore include two results above for Opteron, 32-bit results using the Athlon32 assembly loops, and 64-bit results using plain C with inline assembly.
• The performance for the Pentium 4 EM64T processors disappoints. There are performance problems with many instructions GMP depends on: 64-bit multiply, integer right shift, and conditional moves and set-on-condition instructions all need around 10 cycles, and are not fully pipelined. See also Instruction latencies and throughput for AMD and Intel x86 processors
• The 32-bit 90nm Pentium 4 processors (Prescott) run GMP applications slower than older Pentium 4 processors. The reason is that Prescott has longer latencies for SSE2 instructions and memory loads.
• UltraSPARC 3's poor scores are a result of its inadequate integer multiply support (shortcomings in both ISA and implementation).