Live data from Hacker News

Intel's "cripple AMD" function (2009)

agner.org

31–40 of 131 posts

Re: Intel's "cripple AMD" function (2009)

#31
post #28

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.

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)

#34
post #20

I'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 is not the market leader in compilers, however: It is somewhat rare to come across teams using the Intel compiler, and they tend to be in niche modeling/simulation or financial realms, more often than not with the sort of code that you compile for a specific piece of deployment hardware, compiling again when you move it to something different.

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)

#35
post #16

At 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?

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 improve the performance of Atom too much.

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)

#36

I'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?

I was trying to build WRF from source a few years ago for a project in grad school, and the bulk of the program was one giant file that crashed gfortran when you tried to compile it. So compiling with a non-Intel compiler can present some problems.

Re: Intel's "cripple AMD" function (2009)

#37
post #35
post #16

Earlier 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
post #3

(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...

> Since then Intel settled the lawsuit by paying $10M and agreeing to add the following disclaimer to their compilers

Is it just me or does that not actually fix the problem?

Re: Intel's "cripple AMD" function (2009)

#39
post #31
post #28

Earlier 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.

[deleted]

Re: Intel's "cripple AMD" function (2009)

#40
post #14

Earlier 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.…

Your mention of RDRAND is a great point and made me think about just how many differences there are between different models of CPUs from the same vendor. I assume the differences between different Intel CPUs vastly outweigh the differences between similar Intel and AMD CPUs.
Post reply on HN