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

81–90 of 111 posts

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

#81

Post by phkahler »

mistrial9 wrote: post #59
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…

> x68-64 targets thats a typo .. are you showing a case of AVX instructions not generated by GCC? where are the details here? Is SSE2 from twenty years ago? https://en.wikipedia.org/wiki/SSE2

The original AMD64 extension and associated ABI included SSE2, so vectorization was available on 64bit x86 systems from day one. I think that's at least 17 years if not 20. GCC will use it by default at O2 starting with their next release in about a month. Intel has contributed for a long time but I dont know that this stupidity could be pinned on them. It wouldn't surprise me though.

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

#82

Post by salawat »

hpcjoe wrote: post #74
salawat wrote: post #43

Earlier quoted context omitted.

You call Nvidia driver installation easy? Every bit of "ease" about that is hardly Nvidia's doing.

I'm not sure of what issue you have with my statement. For me, it is a painless download + sh NVIDIA-....run. I have mostly newer GPUs, though the 3 systems (1 laptop and 2 desktops) with older GTX 750ti and GT 560m run the nouveau driver (as Nvidia dropped support for those). Its a 13 year old laptop, and still running strong (linux though). Desktops are Sandy Bridge based. The RTX2060 and RTX3060 are doing fine wit…

My point is, that "single download" or apt command to you is a royal pain in the ass to maintain, and makes things like kernel hacking a royal nightmare, all for Nvidia to play stupid out of tree games with the linux kernel maintainers. Easy "for a subset of users" does not excuse going out of the way to create more friction where none need exist.

But I'm glad your preferred workloads are unaffected. That counts for something I guess.

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

#84

Post by cbozeman »

JoshTriplett wrote: post #64

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

When it comes to Intel, I am, and have been, so disgusted that they held back computing by about 6-10 years by consistently shipping overpriced, barely improved-upon quad-core processors that I:

1. Put nothing shitty past them. 2. Will never ever purchase their products again.

The real problem is the endless pursuit of profit though, instead of the pursuit of ever-advancing, ever-improving technological superiority, and sadly AMD isn't any better in this area I've come to see. The moment they conclusively, provably became better than Intel, they jacked up their price, even though their processors were using the same 7nm process that, at that point, was extremely reliable and had a 93% usable chip ratio.

So it turns out as soon as one company gains superiority they immediately become shitbags focused on money instead of focused on the advancement of technology and mankind. It puts anyone with a moralistic stance on what technology should be and how it should be implemented and distributed into a real pickle.

I was hoping that AMD would be the better company here, especially given they nearly died, but turns out they also are ready and willing to squander the goodwill of those of us who bought their chips not just when they were on the last legs, but also during their recovery period.

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

#85

Post by harry8 »

nomel wrote: post #83
midjji wrote: post #51

So blacklist intel compiler in favor or GCC and CLANG, seems entirely reasonable!

This assumes there's no performance/$$$ loss to switching, that you would have to justify to your org.

For anyone shipping binaries to customers using the Intel compiler could well be considered negligent. Intel have made it clear they will secretly sabotage /your/ customers if you use their tools to make your product and in fact they have done so. They will secretly sabotage you if you aren't a "pure intel" shop. Those actions were and remain completely hostile.

In the light of "Reflections on Trusting Trust" [1]

"Intel cannot be trusted to supply your compiler at any price." That's a point of view that is a lot more than just "a reasonable one to hold." The reflection on Intel and their lack of reckoning having been caught out sabotaging your customers is something any customer of Intel needs to consider - included in that assessment must be the expected value of the $$$ loss of purchasing from Intel. It's really not something anyone can responsibly ignore and fail to assess. Then go ahead and making your responsible and informed engineering and business trade off.

[1] https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...

edit: The point being we all have a bar of "well they wouldn't actually do that" in a purchasing decision. That bar for Intel is dramatically lower as a result of this incident and failure to properly address it in full with a mea culpa and consequences rather than the ongoing minimum action required by the courts and damage limitation we've seen. It is very hard to see how the probability of them secretly sabotaging your goals could have gone down here.

That is what Intel think of their reputation and what they think they can get away with in their response to you.

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

#86

Post by nonplus »

mechanical_bear wrote: post #69
shrx wrote: post #7

Earlier quoted context omitted.

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.

I would love to see a 2022 follow-up from Agner Fog on this. He has work on C++ compilers as recently as 2021 so I'm sure he has recent real world info on the topic.

https://www.agner.org/optimize/#manuals

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

#87

Post by ClumsyPilot »

cbozeman wrote: post #84
JoshTriplett wrote: post #64

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

When it comes to Intel, I am, and have been, so disgusted that they held back computing by about 6-10 years by consistently shipping overpriced, barely improved-upon quad-core processors that I: 1. Put nothing shitty past them. 2. Will never ever purchase their products again. The real problem is the endless pursuit of profit though, instead of the pursuit of ever-advancing, ever-improving technological superiority,…

"So it turns out as soon as one company gains superiority they immediately become shitbags focused on money instead of focused on the advancement of technology and mankind"

That exactly why our economy is stagnating - over the past 30 years many major hard industrues have become uncompetitive oligopolies or cartels, and we have people defending this state of affairs.

Some digital industries are even outright monopolies

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

#88

Post by tedunangst »

jdsully wrote: post #79
JoshTriplett wrote: post #64

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

There are feature flags for formerly slow instructions that are now fast. E.g. rep mov https://www.phoronix.com/scan.php?page=news_item&px=Intel-5....

Which flag should I check for fast PEXT?

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

#89

Post by kxyvr »

stephencanon wrote: post #56
ReleaseCandidat wrote: post #17

Earlier quoted context omitted.

No. There are AMD's AOCL and Apple's 'Accelerate', but of subsets of the MKL only AFAIK. https://developer.amd.com/amd-aocl/ https://developer.apple.com/documentation/accelerate

Accelerate and MKL have some overlap (notably BLAS, LAPACK, signal processing libraries and basic vectorized math operations), but each also contains a whole bunch of API that the other lacks. Neither is a subset of the other. They both contain a sparse matrix library, but exactly what operations are offered is somewhat different between the two. They both have image processing operations, but fairly different ones.…

In case you or anyone else knows, are there other libraries that implement a high performance sparse QR? Really, I need a Q-less QR factorization for sparse matrices. As far as I know, there are only two: one comes from MKL:

https://www.intel.com/content/www/us/en/developer/articles/t...

The other comes from SPQR, which is part of SuiteSparse:

https://people.engr.tamu.edu/davis/suitesparse.html

Part of the issue is that SPQR is dual licensed GPL/Commercial and the last time I checked a license was not cheap. Conversely, MKL has no redistribution fee, so it's been essentially the only option for this factorization if the code can't be bundled in a way compatible with the GPL.

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

#90

Post by tedunangst »

cbozeman wrote: post #84
JoshTriplett wrote: post #64

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

When it comes to Intel, I am, and have been, so disgusted that they held back computing by about 6-10 years by consistently shipping overpriced, barely improved-upon quad-core processors that I: 1. Put nothing shitty past them. 2. Will never ever purchase their products again. The real problem is the endless pursuit of profit though, instead of the pursuit of ever-advancing, ever-improving technological superiority,…

I don't think I'll ever understand why nobody is mad at AMD for producing CPUs even worse than Intel for a decade.
Post reply on HN