CPU dispatching in GMP is flawed
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
> 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