Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel's “Cripple AMD” Function (2019)

agner.org

Post reply on HN
Print view View original

61–70 of 111 posts

Re: Intel's “Cripple AMD” Function (2019)

#61

Post by kmeisthax »

IntelThrowaway1 wrote: post #34
Kon-Peki wrote: post #3

This has been discussed on HN before. I don't condone Intel behavior, but let's be honest here: AMD underinvests in software and expects others to pick up the slack. That isn't acceptable.

The thing that gets me about Intel's culture, as someone who worked there, was that Intel as an organisation was completely unable to actually accept they'd done anything wrong. Ever. There are lots of cases where Intel has either screwed up or done things that were unarguably anti-competitive. It happens at every company, I don't like Uber, but I'm not going to blame Uber today for the fuckery that Kalanick got up t…

I don't think this is dishonesty - it's auteur mentality. In Intel's view, AMD was a second-source vendor that went rogue, and gets to free-ride on their patents because Intel couldn't be arsed to extend x86 to 64-bit. If they had their way, they'd own the x86 ISA interface and all their competition would be incompatible architectures that you have to recompile for. Crippling AMD processors with their C compiler wasn't dishonest, it was DRM to protect their """intellectual property"""[0].

Gelsinger was the head designer on the 486, so he was around during the time when Intel was obsessed with keeping competition out of their ISA and probably has a case of auteur mentality, too.

[0] In case you couldn't tell, I really hate this word. The underlying concepts are, at best, necessary evils.

Re: Intel's “Cripple AMD” Function (2019)

#62

Post by pcwalton »

phkahler wrote: post #52

Worth noting that Intel has dropped their "old" compiler and the newer "Intel" compilers are LLVM based. IMHO they will likely be pulling similar anti-AMD tricks with it and they are keeping their paid version closed source - which is allowed by LLVMs license. RMS was right that compilers should be GPL licensed to prevent exactly this kind of thing (and worse things which are haven't happened yet). On another compile…

> RMS was right that compilers should be GPL licensed to prevent exactly this kind of thing (and worse things which are haven't happened yet).

The problem with this is that it wouldn't solve the problem in question: Intel would just have stuck with their old compiler backend instead of LLVM.

Besides, LLVM wouldn't have gotten investment to begin with if it were GPL licensed, since the entire reason for Apple's investment in LLVM is that it wasn't GPL. Ultimately, LLVM itself is a counterexample to RMS's theory that keeping compilers GPL can force organizations to do things: given deep enough pockets, a company can overcome that by developing non-GPL competitors.

Re: Intel's “Cripple AMD” Function (2019)

#64

Post by JoshTriplett »

If Intel had shipped a library/compiler that did just use feature flags and didn't check the CPU vendor, and the resulting code used features that on AMD ran much more slowly than the equivalent unoptimized code, would people blame AMD for the slow instructions, or blame Intel for releasing a library/compiler that they didn't optimize for their competitor's processor?

This isn't a hypothetical; quoting https://en.wikipedia.org/wiki/X86_Bit_manipulation_instructi... :

> AMD processors before Zen 3[11] that implement PDEP and PEXT do so in microcode, with a latency of 18 cycles rather than a single cycle. As a result it is often faster to use other instructions on these processors.

There's no feature flag for "technically supported, but slow, don't use it"; you have to check the CPU model for that.

All that said, the right fix here would have been to release this as Open Source, and then people could contribute optimizations for many different processors. But that would have required a decision to rely on winning in hardware quality, rather than sometimes squeezing out a "win" via software even in generations where the hardware quality isn't as good as the competition.

Re: Intel's “Cripple AMD” Function (2019)

#65

Post by bayindirh »

pcwalton wrote: post #62
phkahler wrote: post #52

Worth noting that Intel has dropped their "old" compiler and the newer "Intel" compilers are LLVM based. IMHO they will likely be pulling similar anti-AMD tricks with it and they are keeping their paid version closed source - which is allowed by LLVMs license. RMS was right that compilers should be GPL licensed to prevent exactly this kind of thing (and worse things which are haven't happened yet). On another compile…

> RMS was right that compilers should be GPL licensed to prevent exactly this kind of thing (and worse things which are haven't happened yet). The problem with this is that it wouldn't solve the problem in question: Intel would just have stuck with their old compiler backend instead of LLVM. Besides, LLVM wouldn't have gotten investment to begin with if it were GPL licensed, since the entire reason for Apple's invest…

While clang is getting this support because it's not GPL, it's also providing a well deserved competition for GCC, and clang's presence woke the GCC devs to build a better compiler.

All in all I avoid non-GPL compilers for my code, but I'm happy that clang acted as a big (hard) foam cluebat for GCC.

In my opinion, we need a well polished GNU/GPL toolchain both to show it's possible, and provide a good benchmark to compete with. This competition is what drives us forward.

Re: Intel's “Cripple AMD” Function (2019)

#66

Post by Beltalowda »

pcwalton wrote: post #62
phkahler wrote: post #52

Worth noting that Intel has dropped their "old" compiler and the newer "Intel" compilers are LLVM based. IMHO they will likely be pulling similar anti-AMD tricks with it and they are keeping their paid version closed source - which is allowed by LLVMs license. RMS was right that compilers should be GPL licensed to prevent exactly this kind of thing (and worse things which are haven't happened yet). On another compile…

> RMS was right that compilers should be GPL licensed to prevent exactly this kind of thing (and worse things which are haven't happened yet). The problem with this is that it wouldn't solve the problem in question: Intel would just have stuck with their old compiler backend instead of LLVM. Besides, LLVM wouldn't have gotten investment to begin with if it were GPL licensed, since the entire reason for Apple's invest…

> Besides, LLVM wouldn't have gotten investment to begin with if it were GPL licensed. The entire reason for Apple's investment in LLVM in the first place is that it wasn't GPL.

I don't think that's the case; Apple/LLVM actually offered to sign over the copyright to the FSF, under the GPL; from https://gcc.gnu.org/legacy-ml/gcc/2005-11/msg00888.html

> The patch I'm working on is GPL licensed and copyright will be assigned to the FSF under the standard Apple copyright assignment. Initially, I intend to link the LLVM libraries in from the existing LLVM distribution, mainly to simplify my work. This code is licensed under a BSD-like license [8], and LLVM itself will not initially be assigned to the FSF. If people are seriously in favor of LLVM being a long-term part of GCC, I personally believe that the LLVM community would agree to assign the copyright of LLVM itself to the FSF and we can work through these details.

The reason people worked on LLVM/clang is that GCC was (and to some degree, is) not very good in various areas, and had a difficult community making fixing those issues hard. There's a reason a lot of these newer languages like Swift, Rust, and Zig are based on LLVM and not GCC. See e.g. https://undeadly.org/cgi?action=article&sid=20070915195203#p... for a run-down (from 2007, I'm not sure how many of these issues persist today; gcc has not stood still either of course, error messages are much better than they were in 2007 for example).

GPL3 changed things a bit; I'm not sure Lattner would have made the same offer with GPL3 around, but that was from 2005 when GPL3 didn't exist yet. But the idea that LLVM was primarily motivated by license issues doesn't seem to be the case, although it was probably seen as an additional benefit.

Re: Intel's “Cripple AMD” Function (2019)

#67

Post by microtonal »

wmf wrote: post #47
wyldfire wrote: post #14

Earlier quoted context omitted.

Each CPU vendor or each CPU architecture? (genuinely asking, I don't know how it's intended)

Each vendor. Intel BLAS (MKL) has Intel-specific optimizations and AMD BLAS has AMD-specific optimizations. Intel is still acting in bad faith by allowing MKL to run in crippled mode on AMD. They should either let it use all available instructions or make it refuse to run.

The latest oneMKL versions have sgemm/dgemm kernels for Zen CPUs that are almost as fast as the AVX2 kernels (that require disabling Intel CPU detection on Zen).

Re: Intel's “Cripple AMD” Function (2019)

#68

Post by jcranmer »

DiabloD3 wrote: post #23
not2b wrote: post #19

Earlier quoted context omitted.

AMD should concentrate on making LLVM and GCC work great on AMD processors, by contributing the needed code. They are already making some contributions but could be doing more, and they could be funding experts to work on that and giving those experts the information they need.

But they already do this. AMD is one of the largest corporate contributors to LLVM and GCC. It's Intel that tends to phone this in and make everyone else pick up the slack.

Per https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Rec..., Intel actually contributes (slightly) more to LLVM than AMD does.

Re: Intel's “Cripple AMD” Function (2019)

#69

Post by mechanical_bear »

shrx wrote: post #7
mechanical_bear wrote: post #5

So it appears not only is this posting from 2019, but the most recent information they reference is 2010. This seems to be no longer relevant? I’d love it if submissions on HN had a small blurb from the author explaining why their submission is interesting/relevant.

It certainly is still relevant. Please read the article (and the 2020 update below) before commenting on it.

I didn’t state it was not relevant, I asked. Glad to see there is an update. My main point stands though, I’d love to see an explanation with posts.

Re: Intel's “Cripple AMD” Function (2019)

#70

Post by Jap2-0 »

ReleaseCandidat wrote: post #38
not2b wrote: post #19

Earlier quoted context omitted.

AMD should concentrate on making LLVM and GCC work great on AMD processors, by contributing the needed code. They are already making some contributions but could be doing more, and they could be funding experts to work on that and giving those experts the information they need.

They do. Actually their own (LLVM based) compilers are about as fast as GCC and LLVM https://www.phoronix.com/scan.php?page=article&item=aocc32-c...

I don't know if it necessarily says much that their LLVM-based compiler is about as fast as LLVM.
Post reply on HN