5 ms·
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 mu
by JoshTriplett 5y ago
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_instruction_set 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.
- deleted 5y ago[deleted]
- cbozeman 5y agoWhen 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.
- ClumsyPilot 5y ago"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
- tedunangst 5y agoI don't think I'll ever understand why nobody is mad at AMD for producing CPUs even worse than Intel for a decade.
- qball 5y agoThis 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.
- fyver 5y agoI much people upgrade computer parts instead of replacing the whole computer and replace their CPU with every new generation?
- qball 5y agoMaybe, 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.
- jdsully 5y agoThere 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.6-FSRM-Memmove https://www.phoronix.com/scan.php?page=news_item&px=Intel-5....
- tedunangst 5y agoWhich flag should I check for fast PEXT?
- dataflow 5y agoSee [1], or [2] and [3]. [1] https://github.com/as-com/varint-simd/blob/f4c4af672403cc68391ee5dd1d9eb478ce410c8a/build.rs#L17 https://github.com/as-com/varint-simd/blob/f4c4af672403cc683... [2] https://en.wikipedia.org/wiki/X86_Bit_manipulation_instruction_set#cite_note-18 https://en.wikipedia.org/wiki/X86_Bit_manipulation_instructi... [3] https://en.wikipedia.org/wiki/List_of_AMD_CPU_microarchitectures https://en.wikipedia.org/wiki/List_of_AMD_CPU_microarchitect...
- tedunangst 5y agoSo... ignore the cpuid bit indicating the instruction is present and look at manufacturer string, which is exactly what intel is being lambasted for here.
- dataflow 5y agoNo, 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()
- wtallis 5y agoThat 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.