[mpixel]

what's interesting is that this isn't as serious as some of the issues today.

just following the example, the result is wrong after the 4th digit. this is absolutely 'could be handled in software with a significant performance loss' territory.

that isn't to say this isn't breaking -- it absolutely is.

what I'm getting at is that my CPU runs 30% slower with mitigations. if I were running multiple servers like the computer I use, and I was near the capacity of my resources, I would need to add some machine(s) -- and people do.

in the same way this is serious, these current issues are the same yet somehow we've lost some stuff along the way and we just don't do recalls or even receive any remedies. where's my check?

[mjg59]

For the most part, the bugs we've seen in recent history can be handled at the kernel level - there's largely no need for applications to care about them (browsers to an extent being a counterexample, but even then if you disable hyperthreading it can basically be ignored at the browser level). The floating point division bug was something that every single application would need to have handling code for. From a "What is the worst case outcome", the Spectre family of bugs may win. From a "What is going to require the most engineering effort to fix in software", fdiv would probably have been a much bigger deal.

[nextaccountic]

One option would be to have an x86 to x86 compiler that automatically fixed your code. In principle you don't need access to source and it could be shipped by the OS

[rvba]

I have this theory that Intel knew very well what they were doing by cutting corners everywhere. This way their processors were simply faster than the ones manufactured by AMD.

But it was "fake" advantage (due to ignoring bugs) - now that those bugs come out to light, their processors are slower. But were already sold.

And yes I know that AMD has some similar bugs.

The US government will not go after Intel though due to public safety issues - they want their processors to be manufactured at US soil (different thing is if they are really safe with all those bugs and spying features, also are they even manufactured inside USA anymore?).

Other governments could go aftet Intel though.

[hardware2win]

>And yes I know that AMD has some similar bugs.

So, how does your theory stand?

If we assume that both companies were cutting corners and one was ahead, then?

[dfhanionio]

Intel was vulnerable to Meltdown and Spectre. AMD was only vulnerable to Spectre.

Meltdown arose because vulnerable designs delay memory protection checks until as late as possible, after illegal accesses could have already affected state. This is a questionable decision, as it is playing fast and lose with the most fundamental building blocks of security. Most companies wisely chose a more cautious approach.

If an investigation found that watermelon is carcinogenic, that would be a problem. If that same investigation found that Andy's Farm sells watermelon that contains benzene, Andy's Farm couldn't defend itself by saying all watermelon is carcinogenic.

[planede]

Until they got caught out on it competition on performance incentivized both to cut corners on side channel attack surfaces.

[h2odragon]

I've had a notion for years that Intel has intentionally failed to pursue some areas of performance improvement so as to reserve them for "official" users.

way, way back at the beginning of the PC revolution, for example: SRAM vs DRAM? Intel went all in on DRAM. Imagine how different the world could be today if they'd chosen differently an could expect all main RAM to be "cahce latency". DRAM would be a slower dynamic store, possibly looking more like hard drives did.

What if they'd decided that unifying a bus was a good idea instead of tossing out new ones every couple years? Imagine the longevity and variety of the VME bus ecosystem couples with the size of the PC market, in the 80s.

[mrguyorama]

> for example: SRAM vs DRAM? Intel went all in on DRAM.

This isn't really how it went. There was never a future with hundreds of megabytes of SRAM as it requires significantly more die area to produce and more power to use, making it significantly more expensive. The entire point of caches was because we couldn't afford to just make everything SRAM. Even today, we are only just getting to the point where you might have a few hundred megabytes of SRAM on the most expensive server CPUs.

[colejohnson66]

> The entire point of caches was because we couldn't afford to just make everything SRAM.

Because SRAM is expensive compared to DRAM. SRAM requires four transistors per bit, but DRAM requires just one. And that one transistor doubles as your capacitor. In addition, routing makes a single SRAM cell a bit bigger than four DRAM ones (at the same process node). So, DRAM can be packed to densities that are not feasible for SRAM. There's a reason AMD (and others) is/are starting to put cache on an entirely separate die (X3D).

[dale_glass]

We're already up to 1.1 GB of cache:

https://www.servethehome.com/amd-genoa-x-the-1-1gb-l3-cache-...

It's a little bit mindblowing.

[dustfree_mt]

UVM, formal verification, co-simulation through DPI were at their infancy back then, thus such silly(albeit critical) errors kept popping up and were really hard to catch during pre/post-silicon testing.

You can't catch spectre or similar things where multiple blocks all doing the wrong thing together with UVM or formal nowadays either(too large search space), so I'm eager to see what kind of top-level verif. methodologies people will invent as the designs grow larger and larger.