That’s why they called it the Pentium and not the 586: on the bench it kept coming out at 585.9999999. I’m sorry.
To pay my way for the silliness: I will highly recommend “The Pentium Chronicles” for a view into that time and place.
It covers the development of the P6 arch, but there is some inside baseball about the P5. And it’s just one of the best books I’ve ever read about really amazingly well-run engineering efforts.
TIL that wigwam and wickiup are two names for similar enough dwellings that we may consider them the same thing. I always thought that wigwams were bigger. They're usually called wigwams in the northeast among the Iroquois confederacy and wickiups in the southwest among the Apache.
yeah I think my issue stems from getting taught that wigwam was a synonym for longhouse when we learned the terms in school in the Northeast (like dead in the middle of an Iroquois nation). Haudenosaunee (endonym for Iroquois) literally references the longhouse. Wigwam has nothing to do with longhouse! It's an Algonquian word (further East from the Iroquois). Will keep this in mind.
Your comment reminded me that Cyrix had a "586" chip (technically was called the 5x86) and 12 year old me definitely thought it was an Intel when I bought it at a local computer show. Turned out to be a great little processor for the price.
Cyrix was a really fascinating company. Extremely short lived but had a huge impact on Intel's grip over the processor space (Intel lost all their lawsuits against them and nearly faced antitrust proceedings because of it).
I believe there is a lot of overlap between the transcript of an interview Robert Colwell did [1] with his book The Pentium Chronicles. I've read and liked both. I'm linking to archive.org's copy as the original site appears to be defunct.
[1] Oral history of Robert P. Colwell (1954- )
Interviewed by Paul N. Edwards, Assoc. Prof., University of Michigan School of Information, at Colwell’s home near Portland, Oregon, on August 24-25, 2009
When I was running a team that included other managers I bought copies for everyone, and I believe at least one is in a box somewhere. I’ve read it dozens of times so I’m happy to pass it along if I can find it.
No promises (I’ve moved a lot) but if you email me I’ll try to find it and if I do it’s yours.
There are multiple proofs for this, but my favorite simple, yet informal proof, is that there is no real number you can add to 0.999 infinitely repeating to make it 1. So mathematically, they are equal.
Dr. Nicely caused quite a bit of excitement at Intel. I was on the p6 architecture team when he discovered the FDIV bug. Our FPU was formally verified and didn't have the same bug.
To be nice to Dr Nicely we sent him a pre-release p6 development system to test with his program to demonstrate that his bug was fixed. He was working on a prime number sieve program and came back reporting that the p6 ran at 1/2 the speed of a Pentium for his code. Wow, another blackeye/firestorm caused by Dr. Nicely. He had too much of an audience for him to report to the world this new processor was slower.
So I got to spend a lot of time learning how to sieve works and what is happening. For the most part, it allocates a huge array in memory with each byte representing a number. You walk the array with a stride of known primes setting bytes and whatever is left must be prime. ie. every 3 is not prime, every 5 is not prime, every 7...
So in the steady state, you are writing a single byte to a cache line without reading anything. And every write hits a different cache line.
Now p6 had a write-allocate cache, but the Pentium would only allocate on read, so on the Pentium a write that misses the cache would become a write to memory. On the p6 that write would need to load the cache line from memory into the cache and then the line in the cache was modified. And since every line in the cache was also modified we had to flush some other cache line first to make room. So every 1-byte write would become a 32-byte write to memory followed by a 32-byte read from memory.
Normally write-allocate is a good thing, but in this case, it was a killer. We were stumped.
Then the magic observation: 99% of these writes were marking a space that was already marked. When you get up to walking by large strides most of those were already covered by one of the smaller factors.
So if you change the code from:
array[N] = 1
to:
if (!array[N]) array[N] = 1
Now suddenly we are doing a read first, and after that read we skip the write so the data in the cache doesn't become modified and can be discarded in the future.
Also, the p6 was a super-scalar machine that ran multiple iterations of this loop in parallel and could have multiple reads going to memory at the same time. With that small tweak, the program got 4X faster and we went from being 1/2X the speed of a Pentium to being twice the speed. And this was at the same clock frequency. The test hardware ran 100Mhz, we released at 200Mhz and went up from there.
The Pentium Pro is by far the CPU I remember being the most surprised about, and I was an engineer at Intel when it was released. Such an amazing design and manufacturing technique, and 200Mhz with 256 or 512k L2 cache! That seemed like such a huge cache at the time. Performance on video codecs with some tweaks was a 2x jump as well. Funny enough I still have a working Pentium Pro 200 system. good times!
Yea, It was surprising how many years after that the perfect spec developer station was a Pentium Pro, Mach 64 graphics card, monochrome card with mono monitor for WinICE, and of course Windows NT 4.0.
There are a lot of cache-related performance behaviors that can be triggered by the "wrong" code. I was the product for a minicomputer system once and an outside performance consultant stumbled on one of those which caused a bit of a kerfuffle at the time. As I recall, it wasn't really an issue for real-world workloads but if you did things just wrong, it could be a significant performance hit.
It wouldn't be needed today on x86_64. The underlying idea - priming the processor with hints about what and when - is now standard practice. There are explicit instructions for manipulating the cache and marking data as needed-soon. E.g. PREFETCH, available as __builtin_prefetch in GCC. Added to the Pentium III, I think.
I recall my former professor at UT Austin, J Strother Moore, sharing how Intel utilized an Automatic Theorem Prover he helped create to spot bugs in processors. But when engineers tweaked the design just a little, thinking it was a no-brainer that it wouldn't cause issues, they skipped the automated checks.
And just like that, the infamous Pentium bug hit the headlines globally.
My take away from this a lesson about validation strategy. First, I will point out that exhaustive testing for 2^64 * 2^64 operand pairs is impractical, for scale recall that there are around 2^75 (I maybe off a bit here) atoms in the universe. So you wont run all pairs, much less generate expected results for all pairs. So, you must sample. Purely random sampling is mostly going to generate operand pairs that are not edge cases and corner cases, where one or both of the operands falls precisely on a binate boundary (the precise point on the floating point number line where the exponent increments/decrements by 1). Your sampling must be heavier for the edge cases. Lesson: Understand the edge cases and be sure to attack them.
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?
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.
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
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?).
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.
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.
> 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.
> 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).
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.
It's funny how they had to recall the CPUs (even if they tried to make it harder), and now, with all the security issues (from spectre to downfall), where the patches cause a massive CPU performance hit, noone is yelling for a recall.
Well, the "solution" to side channel attacks (including those that haven't been discovered yet) on pretty much every out-of-order execution processor out there, which is to say pretty much every high performance processor, is to disable a lot of features and significantly throttle them--which no one really wants to do.
I don't know about outside the US, but in the US, they had to offer to buy back the cars and/or modify them to fit the environmental spec. I don't know about power specs, but the mileage specs were done under the compliant engine control regime; so post modification you would get mileage to spec as opposed to the better mileage available earlier.
The buy back option was based on pricing before the news broke and for a good condition vehicle, there was an adjustment for odometer miles, but the vehicle could be in any condition, just had to run and move on its own power. They were not permitted to resale purchased vehicles anywhere globally unless they were modified to properly comply with emissions controls.
And they were forced into selling EVs and building a charging network. Maybe that will work out for them, maybe not.
I think it was the first time that the "public at large", even the computer nerds, had really realized that the hardware could have bugs, serious bugs.
My first PC was a Pentium 90 that I got in summer 1994. It had the FDIV bug. I read about the bug, didn't think it was a big deal for how I used my computer and never got a replacement chip. I still have the CPU in a box in the closet.
I have always wondered if anyone was able to construct an interest rate derivatives pick-off play based on this bug. My searches of the intertubes have found nothing so far.
To pay my way for the silliness: I will highly recommend “The Pentium Chronicles” for a view into that time and place.
It covers the development of the P6 arch, but there is some inside baseball about the P5. And it’s just one of the best books I’ve ever read about really amazingly well-run engineering efforts.