Among many flavors of Linux, you chose Gentoo, because it is source-based. Which means software is compiled at your computer, and tuned the way you like (want this library but not that library; want this library with Python bindings and no documentation; want that library without assembly optimization, to test pure C code speed). And of course, you want maximal perfomance by default.

Now you bought a new Haswell CPU which can multiply big integers better than other CPU (as Intel says). That MULX instruction is a lot better, for many reasons. And luckily GMP library has a special optimization for this CPU. You have GMP installed because it is an unconditional dependancy of GCC and thus a core component of your system. So just re-compile the library, and enjoy the faster perfomance.

You check your C flags (-O3 -march=native) and re-compile GMP (emerge sys-libs/gmp). Then produce assembler code (objdump -d /usr/lib/ibgmp.so > /tmp/gmp.s) and inspect __gmpn_mul_basecase subroutine code (that multiplies small-size big ints). Ups, no mulx instruction. You re-check source of this procedure found in gmp-6.0.0/mpn/x86_64/coreihwl/mul_basecase.asm. Lots of mulx.

What the hell? You check emerge log and find suspicious lines like

config.status: linking /tmp/portage/dev-libs/gmp-6.0.0a-r3/work/gmp-6.0.0/mpn/x86_64/k8/mul_basecase.asm to mpn/mul_basecase.asm

How comes that subroutine for k8 is used on your Haswell? You run GMP configure by hand --- it links to Haswell/coreisbr/... code but not k8 code. You go deeper and find out that GMP skips CPU auto-detection when configured via official Gentoo ebuild.

Time to go to Gentoo bug-tracker. You browse thru reported bugs and find the problem reported by yours truly, with 5-line patch that fixes it. Sidenote: The patched .ebuild can be found here.

So the problem is being solved by Gentoo? No, what's that? Resolution: won't fix. With no explanation why (other than reference to bug no. 235697 page containing no clear statement).

Since there is no explanation, we can only guess. Maybe Gentoo has a paid version that runs faster than free publicly available? Or Gentoo team wants installed code to work slowly for some other reason? Or maybe Gentoo team thinks that each and every open-source library should configure itself correctly after config.sub and config.guess are spoilt?

I don't know if the Gentoo decision to keep GMP mis-configured has some policy behind it. Anyway, the decision and the policy (if it exists) sucks. It sucks more than selling modems persuaded to not support all protocols they are capable of. It sucks more than selling car with engine persuaded to not run at full power. While selling castrated modems or castrated car can be easily explained by financial interest of the manufacturer, I can't see how Gentoo or anybody else can benefit from mis-configuring GMP.

Some years ago I thought Gentoo was a Linux aimed at delivering optimal code tuned by the user, easy to manage and upgrade. Now, I confess I do not know what Gentoo is. I think it is correct to say that Gentoo is a Linux based on nice packet manager but whose maintainers take very strange decisions that badly hurt users.

Life teaches us to trust no-one. List of persons or institutions who can be trusted depends on many factors but surely is extremely short. You suspect your car maker of cheating and check an unofficial forum if your car engine wants a software 'upgrade'. You don't want to be the victim of NSA provocation called Windows and choose Linux as your OS. And when choosing among Linux dialects, you know that some distributive maintainers including Gentoo Foundation is definitely not the one to be trusted.

haswell

Why your Gentoo Linux is slow