pendell
2010-01-08, 10:39 AM
Seen in OS News (http://www.osnews.com/story/22683/Intel_Forced_to_Remove_Cripple_AMD_Function_from_C ompiler_)
Here's something you probably don't know, but really should - especially if you're a programmer, and especially especially if you're using Intel's compiler. It's a fact that's not widely known, but Intel's compiler deliberately and knowingly cripples performance for non-Intel (AMD/VIA) processors.
Agner Fog details this particularly nasty examples of Intel's anticompetitive practices quite well. Intel's compiler can produce different versions of pieces of code, with each version being optimised for a specific processor and/or instruction set (SSE2, SSE3, etc.). The system detects which CPU it's running on and chooses the optimal code path accordingly; the CPU dispatcher, as it's called.
"However, the Intel CPU dispatcher does not only check which instruction set is supported by the CPU, it also checks the vendor ID string," Fog details, "If the vendor string says 'GenuineIntel' then it uses the optimal code path. If the CPU is not from Intel then, in most cases, it will run the slowest possible version of the code, even if the CPU is fully compatible with a better version."
It turns out there are some workarounds:
a number of workarounds, such as using GNU GCC, whose optimisations are similar to that of Intel's compiler, "but the Gnu function library (glibc) is inferior". You can also patch Intel's CPU dispatcher - Fog even provides a patch to do so in "Optimizing software in C++: An optimization guide for Windows, Linux and Mac platforms".
Respectfully,
Brian P.
Here's something you probably don't know, but really should - especially if you're a programmer, and especially especially if you're using Intel's compiler. It's a fact that's not widely known, but Intel's compiler deliberately and knowingly cripples performance for non-Intel (AMD/VIA) processors.
Agner Fog details this particularly nasty examples of Intel's anticompetitive practices quite well. Intel's compiler can produce different versions of pieces of code, with each version being optimised for a specific processor and/or instruction set (SSE2, SSE3, etc.). The system detects which CPU it's running on and chooses the optimal code path accordingly; the CPU dispatcher, as it's called.
"However, the Intel CPU dispatcher does not only check which instruction set is supported by the CPU, it also checks the vendor ID string," Fog details, "If the vendor string says 'GenuineIntel' then it uses the optimal code path. If the CPU is not from Intel then, in most cases, it will run the slowest possible version of the code, even if the CPU is fully compatible with a better version."
It turns out there are some workarounds:
a number of workarounds, such as using GNU GCC, whose optimisations are similar to that of Intel's compiler, "but the Gnu function library (glibc) is inferior". You can also patch Intel's CPU dispatcher - Fog even provides a patch to do so in "Optimizing software in C++: An optimization guide for Windows, Linux and Mac platforms".
Respectfully,
Brian P.