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

101–110 of 111 posts

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

#101

Post by dataflow »

tedunangst wrote: post #100
dataflow wrote: post #99

Earlier quoted context omitted.

See [1], or [2] and [3]. [1] https://github.com/as-com/varint-simd/blob/f4c4af672403cc683... [2] https://en.wikipedia.org/wiki/X86_Bit_manipulation_instructi... [3] https://en.wikipedia.org/wiki/List_of_AMD_CPU_microarchitect...

So... ignore the cpuid bit indicating the instruction is present and look at manufacturer string, which is exactly what intel is being lambasted for here.

No, you don't ignore the CPUID feature bit. You use the CPUID to enable the feature by default, but override that default by blacklisting specific models that you know would have undesirable implementations.

So what you would do for PDEP/PEXT would be

  use_pdep = cpuid.supports_bmi2() && !cpuid.is_amd_before_zen3()
and not

  use_pdep = cpuid.is_intel_haswell_or_later()

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

#102

Post by BlueTemplar »

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,…

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

Why wouldn't they have jacked up their price, if provably better ?

It's not like this happened on its own, without more effort from AMD (or less from Intel) ?

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

#103

Post by BlueTemplar »

DSingularity wrote: post #95

> After Intel had flatly denied to change their CPU dispatcher, I decided that the most efficient way to make them change their minds was to create publicity about the problem. I contacted several IT magazines, but nobody wanted to write about it. Sad, but not very surprising, considering that they all depend on advertising money from Intel. Sorry to go on this tangent: but is capitalism so rotten that everything eve…

Strictly speaking, it's not about "capitalism", but journalists trying to get funding from anywhere else than directly their readership. (There used to be law proposals forbidding this, not sure if advertising was already on their radar back in the 1940's.)

Of course there would still remain the issue of self-censoring to avoid annoying your readership, not sure how you can deal with that...

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

#104

Post by gpderetta »

wtallis wrote: post #96
jdsully wrote: post #79

Earlier quoted context omitted.

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

That feature flag is merely a macro in the Linux kernel source code, and doesn't appear to be exposed to userspace. It is entirely different from the kind of flags under discussion, which are in the return values of the CPUID instruction and available for any program to query.

from the patch:

The enhancement applies to string lengths between 1 and 128 bytes long. Support for fast-short REP MOVSB is enumerated by the CPUID feature flag: CPUID [EAX=7H, ECX=0H).EDX.FAST_SHORT_REP_MOVSB[bit 4] = 1

So there is indeed a CPUID feature flag for fast rep movsb.

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

#105

Post by washadjeffmad »

tedunangst wrote: post #90
cbozeman wrote: post #84

Earlier quoted context omitted.

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.

Go back and benchmark your old Intel CPUs with security mitigations enabled. You'll lose 30-60% performance in syscall heavy and other common workloads while Bulldozers barely change.

Intel gained an unfair advantage and built their reputation by taking shortcuts with security. The FX series weren't marvels of design engineering, but they weren't nearly as behind the performance curve as customers were deceived into thinking.

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

#106

Post by stephencanon »

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

Replying to [dead] sibling post from kxyvr: yes, Accelerate provides a Q-less sparse QR on Apple platforms (https://developer.apple.com/documentation/accelerate/sparse_..., in particular SparseFactorizationCholeskyAtA). I believe that MA49 from HSL does it as well, and may have more acceptable licensing than SuiteSparse depending on your situation.

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

#107

Post by ksec »

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,…

Wat?

It was only by the end of 2020 AMD has managed zero debt and bought back their own HQ which was previously put on as collateral.

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

#108

Post by qball »

fyver wrote: post #97
qball wrote: post #94

Earlier quoted context omitted.

This probably has a lot to do with the anti-consumer segmentation and processor locking that Intel implemented at the dawn of the decade- arbitrary socket changes every 2 years so you couldn't upgrade without buying a new motherboard, and locking overclocking behind a paywall being the two most egregious. AMD's processors, while not fast, did none of those things and were cheap. I guess that buys you a lot of good wi…

I much people upgrade computer parts instead of replacing the whole computer and replace their CPU with every new generation?

Maybe, but the people that drive the hate for Intel online all fall into the former category.

And "have to replace the motherboard along with the CPU" is the exact thing we're talking about here: there was no technical reason for Intel to make the earlier boards incompatible, they did it just because they could. Not that there was ever really a reason to upgrade beyond "buy the cheapest K series, set multiplier to 46-48x, done", but even if you wanted to, you couldn't.

It was an anti-consumer practice and said consumers never forget it (not that most tech channels don't provide active reminders of it). And those people are who everyone else asks when "I'm getting a new computer", they say "buy the competitor's product", and the rest is history.

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

#109

Post by midjji »

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.

I almost wish my org knew enough to make such policies.

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

#110

Post by arendtio »

tedunangst wrote: post #90
cbozeman wrote: post #84

Earlier quoted context omitted.

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.

Actually, I am mad at them for creating that Bulldozer mess. Nevertheless, it is good to have some competition back in the game.
Post reply on HN