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

91–100 of 111 posts

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

#91

Post by Cloudef »

hpcjoe wrote: post #72
Cloudef wrote: post #29

Earlier quoted context omitted.

AMD is best on the linux right now. But thats mostly thanks to them opening up their hardware for driver developers.

I was getting better performance out of the NVidia HPC SDK compilers, but then again, the old PGI compilers it is based upon (with an LLVM backend now), have always been my go-to for higher performance code. I've got some Epycs and Zen2s at home here, and I have both compilers. Haven't done testing in recent months, but they've been updating them, so maybe I should look into that again. Thanks for the nudge!

Ah, I should've clarified here I mainly meant the GPUs :) Though keep in mind if you do computing (through CUDA), nvidia is still necessary.

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

#92

Post by ClumsyPilot »

kmeisthax wrote: post #61
IntelThrowaway1 wrote: post #34

Earlier quoted context omitted.

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…

> In Intel's view, AMD was a second-source vendor that went rogue, and gets to free-ride

In Russia's view Ukraine is a breakaway province that was getting a free ride from all the transit gas fees and must be brought to heel.

In medieval mentality women are property

What i mean is, its really a tool to justify why your dishonest behaviour is okay

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

#93

Post by not2b »

Jap2-0 wrote: post #70
ReleaseCandidat wrote: post #38

Earlier quoted context omitted.

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.

It says they might as well stop dividing their effort and focus on the upstream LLVM (or alternatively treat their own version as just a development branch that they can push upstream from). While they have expertise on the details of their processor they may benefit more by cooperating with all the compiler experts outside their company.

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

#94

Post by qball »

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.

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 will when Intel's still charging 300 dollars for CPUs that wouldn't beat a 2500K at 4.6GHz until several years down the line.

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

#95

Post by DSingularity »

> 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 eventually corrupts? Here even outlets for discussion on topics of science and technology self-censure to maximize profit. So much for freedom of speech.

Where is truth these days?

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

#96

Post by wtallis »

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

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.

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

#97

Post by fyver »

qball wrote: post #94
tedunangst wrote: post #90

Earlier quoted context omitted.

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

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?

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

#98

Post by cbozeman »

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.

AMD didn't have the technical prowess to do it, that's why. And even if they had, the Wintel duopoly was so entrenched that even if their offerings were "nearly as good as" Intel's, they still wouldn't have been able to make headway because Intel was threatening OEMs like HP, Dell, etc.

If Jim Keller hadn't gone back to help AMD, and if Dr. Lisa Su hadn't decided to take on that challenge, we'd likely be stuck in an era of processor Dark Ages, OR, Apple and their Apple Silicon line of processors would be even more attractive than they already are.

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

#99

Post by dataflow »

tedunangst wrote: post #88
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....

Which flag should I check for fast PEXT?

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

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

#100

Post by tedunangst »

dataflow wrote: post #99
tedunangst wrote: post #88

Earlier quoted context omitted.

Which flag should I check for fast PEXT?

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.
Post reply on HN