CPU dispatching in GMP is flawed

Agner Fog agner at agner.org
Mon Aug 9 15:14:23 CEST 2010

Jonathan Blanchard wrote:
> speed is just 'nice to have' but never at the price of
> portability. (Now with a grain of salt here but still.)
Speed can be critical in arbitrary-precision math, but I agree that the 
gain obtained by fine tuning assembly code may be relatively small. My 
main concern here is that it is not fair that the code gives "unknown" 
processors such as VIA the slow generic code, while Intel and AMD get 
the faster versions. CPU dispatching should be based on instruction sets 
for unknown processors.
>  Also this
> discussion appears to be mostly related to the way x86 cpu handles the
> mess they created by having half a million instruction sets.
New instruction sets are introduced for improving speed - or for fooling 
consumers into buying a new computer every year :-)
Non-x86 architectures are adding vector instructions as well in order to 
stay competitive.
> Let's not forget the difference between a distribution and an
> optimized version of GMP. OS or software distribution will provide
> baseline binaries that should work with acceptable results on all
> supported architecture. One of the advantages of free software to the
> area of numerical computing is the ability to build optimized binaries
> for their computing platform. This kind of negate the need for runtime
> detection since it would be disabled in that case where performance
> matter the most.
Mathematica uses the fat binary with CPU dispatching. I don't know what 
other applications do
> Finally I would just like to add that there is other ways to select
> optimized binary at runtime, whether it's a functionality of the
> dynamic linker or the application.
Runtime dispatching in the linker has recently been added to Linux. It's 
not available in Windows.

More information about the gmp-discuss mailing list