Earlier quoted context omitted.
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.
Intel's "cripple AMD" function (2009)
31–40 of 131 posts
Re: Intel's "cripple AMD" function (2009)
#32I know, their compiler produces the fastest code, but maybe you can get good (enough) results by using libraries and maybe some manual optimization
Re: Intel's "cripple AMD" function (2009)
#33http://www.engadget.com/2009/05/13/intel-fined-1-45-billion-...
Re: Intel's "cripple AMD" function (2009)
#34I'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…
Intel makes the ICC seemingly to try to encourage the adoption of newer features in newer processors -- multi-threading for many-core processors, SSE, SSE2, SSE3, AVX, AVX2, soon AVX-512, etc. It is worth noting that simply using a feature (e.g. SSE, AVX) because it is there does not guarantee performance improvements in all scenarios -- the ICC uses specific model timings to make some of its choices.
The obvious solution for this problem is to never have a reason to use the ICC compiler. For the auto-vectorization and use of things like AVX be as advanced in gcc, llvm, and even the Microsoft compiler.
Re: Intel's "cripple AMD" function (2009)
#35At this point, does intel need that function to make AMD's CPU cores look bad?
You're talking about a company whose motto is "only the paranoid survive". Why win when you can utterly dominate?
They only started caring about power consumption when it was already obvious to everyone that ARM is going to pose a threat to them eventually. I think if everyone sees something that's by definition not "paranoia". To be paranoid, you have to see and believe something before others see it.
Re: Intel's "cripple AMD" function (2009)
#36I'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)
#37Earlier quoted context omitted.
You're talking about a company whose motto is "only the paranoid survive". Why win when you can utterly dominate?
I don't think that's been their motto since Otellini took over. Look where they are now in the mobile market. Otellini put the profitability of their Core chips above improving Atom in the first few years, even when it came to netbook performance, which was already terrible. Combined with the fact that they forced OEMs to not buy AMD alternatives during the same time, Otellini just didn't think it's necessary to impr…
They only started caring about power consumption when
it was already obvious to everyone that ARM is going to
pose a threat to them eventually.
I'm being a bit pedantic, but it seems to me they refocused on power consumption beginning with the launch of the Pentium M (forerunner of the Core and Core 2 lines) which was released in 2003 and was surely in development several years before that.Or do you think they were thinking ahead to ARM already in ~2001 or so? Maybe they were... although I think they were thinking about targeting laptop sales in general at that point, not ARM specifically.
Re: Intel's "cripple AMD" function (2009)
#38(2009) Since then Intel settled the lawsuit by paying $10M and agreeing to add the following disclaimer to their compilers: "Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors..." http://software.intel.com/en-us/articles/optimization-notice... http://www.anandtech.com/show/3839/intel-settles-with-the-ft...
Is it just me or does that not actually fix the problem?
Re: Intel's "cripple AMD" function (2009)
#39Earlier quoted context omitted.
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.
The problem is that they penalized AMD without telling anyone. The market only works if you know what you're buying.
Re: Intel's "cripple AMD" function (2009)
#40Earlier quoted context omitted.
Couldn't that also potentially break some logic branch through the chip where the app is expected to be running on a GenuineIntel processor? I'm not well versed in this.
Not likely. AMD processors are very carefully designed to correctly execute code, even if it just assumes GenuineIntel and never even checks. If code is dumb enough to try to use something low-level (let's use Bull Mountain RDRAND as an example) without checking for that specific feature bit, then it obviously is the code that is broken, leading to an illegal operation and it gets killed. That's not the CPU's fault.…