Hacker News Reader

Comment by Cyph0n | Hacker News Reader

That's a bit too extreme, don't you think? Disliking AMD is one thing, but claiming that the entire initial run of an AMD processor might be faulty is just silly.

My guess is that you have no idea how much effort goes into verification and testing of something as complex as a microprocessor. A significant chunk of NRE costs goes into verification and test AFAIK.

View on HN

Around 80-85% is the projected cost of Verification and Validation (pre/post - Silicon). This is what historical data shows for us (as a CPU design firm doing ARMV8)

In fairness, there's precedent.

Though that was the FPUs in Intel processors, not AMD. So it's not very good precedent.

Intel's FDIV bug was an outlier. Besides, nowadays most of the ISA is implemented in microcode[1]. There are two advantages to this approach: 1) it is much easier to verify the microcode unit (it's simpler/smaller), and 2) it allows CPU vendors to "fix" ISA implementation issues post-release by issuing microcode updates.

[1]: ISA => microcode is equivalent in some respects to C => LLVM IR

Outlier? I would say uncommon but not an outlier. Here's a non-exhaustive list. http://wiki.osdev.org/CPU_Bugs

There was also an issue with transaction memory with both Haswel & Broadwell. The fix was to disable TSX support via micro code update. I wouldn't call disabling a fix personally. I doubt Intel even compensated the folks who bought it for the TSX support.

Given how many Intel/AMD/etc. CPU releases there have been, I would still refer to such glaring implementation bugs as outliers.

Yeah, that list is far from exhaustive. Years and years ago, Google's websearch cluster validation suite found a tricky bug that isn't on that list. The exchange with the CPU manufacturer was amusing.

Most of the ISA may be implemented in microcode, but the parts that matter are certainly not microcoded!

For example the TLB access and the fast path of the TLB miss are not microcoded. You only get to microcode if you have to set an accessed bit or a dirty bit, or if there is a page fault.

Not really. AMD's Phenom was a flop and the initial batch had a horrible TLB bug. Their FX processors were also hugely hyped and hugely disappointing.

OP said "will [they] even work?". That's a very different thing from a TLB bug. Although I concede that depending on the nature of the TLB bug, it may lead to a significant performance hit.

Regarding your criticisms of AMD's past processors, are you coming at this from a consumer standpoint, or are you just disappointed with their architecture and/or implementation?

I ask because the Phenom II seems quite loved by its users[1], and the FX series was also quite good for its price. I had a FX-8320 in my last PC and it was quite a capable CPU in my opinion, and many others seem to agree[2].

[1]: https://www.newegg.com/Product/Product.aspx?Item=N82E1681910...

[2]: https://www.newegg.com/Product/Product.aspx?Item=N82E1681911...

For datacenter operators there is no difference between "performance is so crippled that the TCO doesn't pencil out" and "does not work." No difference at all.

My guess is you haven't been in this business long enough to comment. Rev. A AMD "Barcelona" parts did not work in any meaningful way. They all had to be thrown out.

http://www.tomshardware.com/forum/246780-28-issues-stop-ship...

Reply on news.ycombinator.com