This all seems to indicate that the intel compiler emits multiple, cpu-dependant code paths for a given binary, which seems insane to me due to the amount of extra memory that this would require. Am I missing something here?
Intel's "cripple AMD" function (2009)
21–30 of 131 posts
Re: Intel's "cripple AMD" function (2009)
#22This all seems to indicate that the intel compiler emits multiple, cpu-dependant code paths for a given binary, which seems insane to me due to the amount of extra memory that this would require. Am I missing something here?
Probably no more insane than loop unrolling, which I understand is fairly standard and well-accepted.
Re: Intel's "cripple AMD" function (2009)
#23How does the Intel compiler compare to others today? We tried using it for game development years ago and it had too many problems to make it worthwhile (e.g. pathological behavior with some C++ code).
I'm disgusted by their intentionally poor performance on AMD, but Intel's compiler is excellent. I often optimize numeric and SIMD functions for x64 on Linux, and regularly compare the generated assembly code of current versions of GCC, CLang and Intel compilers. I have no experience with MSVC. I'm often using the C++ compiler, but the code is usually straight C and inline assembly.
In my anecdotal opinion, Intel produces faster and better code than GCC and CLang about 2/3 of the time, with GCC usually second, and CLang slowest. I love the idea of CLang, but so far find it's main advantage to be clearer error messages rather than fast code.
Bugwise, I think they all are about equal. Intel's weakness right now (for my work) is that it crumbles under very high vector register pressure. And as a free academic licensee, support seems limited to posting on a forum and hoping a relevant Intel employee wanders by.
If I had just one shot for a compile and was hoping for the best outcome without being able to test and verify, I'd compile with Intel. But considering that GCC comes with source, has a much larger community, and accessible bug trackers, it's probably a better day-to-day compiler. But if you are trying to maximize performance, you should definitely try out Intel.
Re: Intel's "cripple AMD" function (2009)
#24This all seems to indicate that the intel compiler emits multiple, cpu-dependant code paths for a given binary, which seems insane to me due to the amount of extra memory that this would require. Am I missing something here?
Usually code isn't that big and maybe these optimizations are only used sparingly so that most of the code is shared.
Re: Intel's "cripple AMD" function (2009)
#25I'm still not entirely sure why is Intel forced to do this? Is it only because they advertise that it optimizes equally well for any CPU? If not, then I don't really see why they can force them to provide another AMD-friendly version.
It's because they specifically check for an intel chip, but the 'intel-optimised' version is also faster on AMD chips than the default (and they are well aware of this). Regardless of their advertising it's a scummy and anticompetitive move.
Re: Intel's "cripple AMD" function (2009)
#26I'm still not entirely sure why is Intel forced to do this? Is it only because they advertise that it optimizes equally well for any CPU? If not, then I don't really see why they can force them to provide another AMD-friendly version.
Intel is the market leader by a good margin, and in the past has been known to use unfair tactics to keep other players out of the market. AMD has been in a lot of lawsuits with Intel due to this.
In this case, it's not just that Intel isn't playing nice with AMD, it's that they're specifically using poor optimizations during compile if you're not using an Intel processor. That's not by accident, that's done on purpose to make non-Intel processors seem worse. What you're allowed to do while competing in the market changes when you're the dominant player in the market.
Re: Intel's "cripple AMD" function (2009)
#27I've ran into it in practice a few years back, while making WRF (math intensive atmospheric modeling software, I'm maintaining non-commercial soaring prediction site for the bay area) to work on my AMD cluster. Had to patch the executable compiled with the Intel compiler in order to make it work unhindered on AMD's. The patch was just zapping 'Genuine Intel' detection code in the compiled executable... That 'post-lin…
Why not just recompile wrf from source? Dependency hell?
Re: Intel's "cripple AMD" function (2009)
#28I'm still not entirely sure why is Intel forced to do this? Is it only because they advertise that it optimizes equally well for any CPU? If not, then I don't really see why they can force them to provide another AMD-friendly version.
Intel is the market leader by a good margin, and in the past has been known to use unfair tactics to keep other players out of the market. AMD has been in a lot of lawsuits with Intel due to this. In this case, it's not just that Intel isn't playing nice with AMD, it's that they're specifically using poor optimizations during compile if you're not using an Intel processor. That's not by accident, that's done on purpo…
I am usually not a free market extremist, but if Intel makes an excellent software product after years and millions of dollars in R&D, and make it only work for certain platforms, power to them.
Re: Intel's "cripple AMD" function (2009)
#29I'm still not entirely sure why is Intel forced to do this? Is it only because they advertise that it optimizes equally well for any CPU? If not, then I don't really see why they can force them to provide another AMD-friendly version.
Yes, the this part of the settlement was based on buyers of Intel's compiler being misled into thinking that it produced good code for all processors. Intel is not forced to change their compiler to produce reasonable code on AMD, only to disclose this practice.
http://www.anandtech.com/show/3839/intel-settles-with-the-ft...
Intel's behavior continues to be scummy and reprehensible, but by adding the disclaimer to all pages regarding the compiler they are now legally compliant. Still, it's a good enough compiler that at times it may be worth using and patching the binary to avoid their dirty tricks.
Re: Intel's "cripple AMD" function (2009)
#30I've ran into it in practice a few years back, while making WRF (math intensive atmospheric modeling software, I'm maintaining non-commercial soaring prediction site for the bay area) to work on my AMD cluster. Had to patch the executable compiled with the Intel compiler in order to make it work unhindered on AMD's. The patch was just zapping 'Genuine Intel' detection code in the compiled executable... That 'post-lin…
Why not just recompile wrf from source? Dependency hell?
Probably it wouldn't work so nice with other compiler. This level of optimization often requires compiler - specific syntax.
Not to say Intel optimization is really good.