Comment by JoshTriplett | Hacker News Reader

Comment by JoshTriplett | Hacker News Reader

Parent Full thread

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.

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.

"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

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

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.

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.

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

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.

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.

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.

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.

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.

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

Reply on news.ycombinator.com