If this includes OS X, I would love to see a source.
Intel's math libs are often 4-5x times faster - if you do a microbenchmark of a loop of powf() or sin() functions, it'll be that much faster using the Intel libs.
If building with fmath=fast for fast floating point math, Intel's fast versions are also quite a bit more accurate, and done't produce nans or infs as much.
Do you happen to remember which one? There have been a few "sporks" of glibc in the last few years and, if memory serves me correctly, Debian now use eglibc.
I think the sporks were done to address bloat, but I'm also curious if they address speed.
The vectorised code the compiler produces is also a lot better.
Private companies who deals with CFD (Computational Fluid Dynamics) and Aerodynamics simulations are companies with deep pockets and who generally pay for a bunch of licenses of these compilers, it's not a small market, I can assure you that.
For normal desktop applications it probably doesn't make sense.
But I doubt that it's really worth it. As I said the real advantage was numeric stuff. I doubt that the Kernel will show any real improvement.
Oh and support as well, very important in big companies.
One in Turbo Pascal 5.5, which allowed to use local variables as the function name.
Another one in IBM JDK in Linux, which produced core dumps.
Both were discussed with their respective vendors.
On that note, the whole list looks like it was written from the point of view of gcc. Features on other compilers that vary from gcc are given 'partial' credit, since I guess they do it differently and different is bad. And extensions in other compilers are not mentioned at all.
It looks like the 'shootout' was done by standing in gcc's corner and taking pot-shots at everybody else in the room.
And ICC tends to do quite well, though "twice as fast" is pretty spun (I'm sure there's a vectorizable routine somewhere that does that, certainly most typical code is going to be more in the "even to 10% better" range).