Slashdot Mirror

But apparently parent end user doesn't remember that Intel had a recall and replaced every CPU that an end user reported to them.

For that matter, Thomas Nicely, the guy who actually did the tracking down of the bug, not you, isn't nearly as bitter as your message makes you appear, and chided Intel for destroying the remaining known defective chips because the defect just wasn't a very big deal to anyone not doing statistical analysis or because the likelihood of anyone doing divides of values like 4195835.0/3145727.0 in floating point while playing a game, using Microsoft Word, PowerPoint, or even doing Excel was very, very low. The chance of them noticing was significantly smaller. Doesn't mean that the bug should have ever cleared validation (I have done validation for Motorola chips in my past life, so I have more than a modest knowledge of what is involved in catching things like this), but I think the anonymous coward doth protest too much. Chances are if you were one of the 1% of users who owned a Pentium of that era and were actually affected in a way that you were able to recognize, then you also knew about the recall.

If you really thought that any CPU you owned prior (or since) that time hasn't had known errors in them and yet still shipped, learn how to read publicly available erratas. Those won't scare you, though, it is usually the ones only available under NDA that tend to be the frightening ones.

And I say that as a person who has never bought an Intel CPU in a notebook computer until 2 months ago.

Bullshit.

1. The web was very much alive when the FDIV bug was discovered.
2. I seriously doubt you as a teenager spent 2 weeks finding this bug, this guy (who happens to be the one who found it) spent some weeks digging through everything to prove it was the FPU that bit him:
http://www.trnicely.net/pentbug/pentbug.html

Oh, and even when the "computer is wrong" it's still a human error.

One-in-a-few-billion problem ?

At that time, I was programming a network game about trucks, and when when replaying a demo on the network, the players desynchronized after a few minutes.

I spent a lot of time looking into the logs, and discovered that there was a floating point error that desynchronized the trucks.
I still believe that the FDIV bug was much more frequent than publicized, and it had more impact than what Intel originally described.

Intel released a software patch to Watcom C++ library, but the patch was terrible, with the FDIV replaced with a lot of instructions just to detect the cases where the bug might appear, and use shiftings instead of FDIV.

I think that the bug was much publicized because it was the beginning of Internet, where a lot of new information went unfiltered, and Intel completely missed their communication on this bug discovered by Thomas Nicely.
Here is the whole story behind this bug:
http://www.trnicely.net/pentbug/pentbug.html

The Pentium FDIV (Floating point divide) bug was not due to a hardware glitch. The error originated in the system level design the lookup table (LUT)used in the IC. All the subsequent verification was against the expected results from the LUT, so the CPU passed all the verification tests. The bug was due to a bad system level design that was never verified - until after the hardware shipped.

from http://www.trnicely.net/pentbug/pentbug.html:
"... The difficulty apparently arises from an error in the
lookup tables used to implement the hardware division algorithm;
the lookup tables are either incorrect or incomplete. ..."

Indeed! Just today, I read a story about using GCC (the Gnu C compiler/GNU Compiler Collection) that is used heavily in Linux. It can also be used to create programs on windows systems, and has always done so quite well, however, under Vista, it can only allocate a maximum of 32 megabytes of memory.

The story is here (just googled it).

http://www.trnicely.net/misc/vista.html

Then you REALLY need to get new MBA textbooks, since the one you have been reading is too politically correct to be useful. Here is a link from the guy who discovered the bug which includes a timeline (I can't believe his FAQ is still online!)...

http://www.trnicely.net/pentbug/pentbug.html/

Pay close attention to questions 9, 10, and 11. It explains what REALLY happened, and the author's opinions on the matter, which to my memory are quite accurate. How do I know? At the time I owned a Gateway Pentium 90 that I could use the Windows calculator on to verify the bug. So once Intel announced the recall, I called to get mine replaced. The box they shipped the replacement in was about 12" x 12" x 8" and very overpadded...way larger than the boxes they ship processors in now for sale. I had to replace my Pentium, box it up and send it back to Intel, and I had to give them my credit card number so that they could bill me $500 ($600?) if I failed to return the old CPU.

...and I'm going to list a few improvements here that I think the author missed.

In one of the early programs, the author had the idea of skipping all even numbers, which are of course divisible by 2. In the next program he found out how he could skip numbers divisible by 3. One can make a systematic method out of that -- in the literature it's known as adding a wheel to the sieve of Erathostenes. Thing is, he implemented the sieve of Erathostenes foregoing this improvement he had implemented earlier. This leads to a big improvement: when using a wheel with the first four primes 2,3,5,7, there are only 48 residue classes out of 210 = 2*3*5*7 possible that are not divisible by any of these four primes. In practice this means that, for each 210 numbers you'd consider, the sieve would only need be applied in 48 of them. That's a gain of 4.375. One can make a gain of nearly 5 using a wheel of the first five primes, but it begins to get complicated.

Another improvement would be to make the program cache-friendly. He sort of did this, down one level of the memory hierarchy, by paging the data to disk -- now he only needed to realize that, just as memory is much faster than disk, cache memory is faster than main memory. I've developed a sieve employing this optimization and it pays off indeed. This is considered a basic technique in the realm of high-performance computing. (The NFSNET, see my sig, uses a sieve including this and other optimizations, for instance).

I might get flamed for this, but he should consider assembly programming. There aren't many applications where assembly will pay off so handsomely as this one, and the `core' of the sieve is very small, so only a few lines of assembly are needed. Vector integer instructions, such as MMX and the integer instructions of SSE2, can be employed to very good advantage here. My sieve program also included this, and it gives a real nice boost -- and only about 25 lines of assembly were used, the rest was C.

Lastly there's the issue of representing the output. He stored the primes on disk by writing their values. A little compression can be realized in this representation: for instance he's printing out the primes in decimal, while hexadecimal would be more space-efficient. And instead of printing out the ASCII characters from 0 to 9, A to F, he could use a binary representation and read them through an hex dump -- that saves half the space, as a byte is used to store two hexadecimal digits instead of one.

A perfectly good representation that could save a lot of space (8 times, to be precise) would be a bitmap, which he used on some of his programs. That's where you represent primality or lack of it by setting and clearing bits of an integer. It's pretty easy to determine a prime from a bitmap value, so this representation is just as good as the previous one. One could also use the wheel idea I explained before to save even more space: a concrete example would be that for each block of 210 numbers, one needs only bitmaps for 48 of them, as the rest are divisible by the first four primes. In this example a savings of 4.375 would be realized. Of course, all these ideas would require special readers programs, instead of just opening up the files in a text editor -- a small price to pay for such a large space savings.

But in case only sequential reading of the primes is desired, there is an even more efficient representation: just write out the prime gaps, i.e. the difference between consecutive primes. One bit can be saved by realizing that, other than 3 - 2, all prime gaps are even, so one can just store the prime gap divided by two. One could really nitpick and point out that 0 is an impossible prime gap, so one could subtract two from all gaps, but this gain is too small to be worth the hassle. According to Thomas Nicely (incidentally the guy who discovered the bug on the Pentium FPU during his studies on computational number theory), one could store the prime gaps of all