FDIV bug in Pentium chips!
Dik T. Winter
> This is just a pointer to a discussion started a few days ago over in
> comp.sys.intel, re a problem with floating point divisions on Pentium
> cpus.
This is a follow-up from comp.arch, cross-posted to comp.arch.arithmetic
and comp.sys.intel with comp.arch left out from the follow-up newsgroups
(to make everything a bit more difficult ;-)). For the readers of c.a.a it
includes part of another message from c.s.i.
>
> Followups should probably be directed to c.s.i to avoid cluttering the
> news-groups.
I included c.a.a as it has relevance for that newsgroup.
>
> It seems FDIV is only carried out to about 29 bits of resolution in the
> mantissa, which is OK for single precision, but totally absurd for a chip
> that claims IEEE extended real (80-bit, 64 in mantissa) conformance.
>
The post by Andreas Kaiser seems to imply that is not really true; here
follows the relevant part:
In article <783979...@ananke.s.bawue.de> a...@ananke.s.bawue.de (Andreas Kaiser) writes:
> Usually, the division is correct (what did you expect?). Just a few
> operands are divided wrong. My results (P90) with ~25.000.000.000
> random arguments (within 1..2^46), with even results divided by two
> until odd, to assure unique mantissa patterns (the binary exponent
> doesn't care, of course).
Followed by a list of 23 numbers for which the division goes wrong.
I have rearranged the list, giving the normalized mantissa in binary
(and indeed, exponent appears to be irrelevant):
1000111111111111111000110101111000010101000100 = 9895574626641
1010011111111111111101101101011000010010100000 = 1443107810341
1011111111111111111110111000001000110111101101 = 52776539295213
1011111111111111111110111000001001100100000000 = 206158356633
1011111111111111111110111000001001110011111100 = 13194134824767
1011111111111111111110111000001001111110111010 = 26388269649885
1011111111111111111110111000001010001111110010 = 26388269650425
1011111111111111111110111000001010010100000101 = 52776539301125
1011111111111111111110111000001010011100010101 = 52776539301653
1011111111111111111110111000001010110011010010 = 26388269651561
1011111111111111111110111000001011000000000000 = 12884897291
1011111111111111111110111000001011001000001100 = 13194134826115
1011111111111111111110111000001011111100101111 = 52776539307823
1011111111111111111110111000001100001000011100 = 13194134827143
1011111111111111111110111000001100011100000100 = 13194134827457
1011111111111111111111101110000010000101100010 = 26388276711601
1011111111111111111111101110000010011000101100 = 13194138356107
1011111111111111111111101110000010101011010110 = 26388276712811
1011111111111111111111101110000010110111011111 = 52776553426399
1011111111111111111111111011100000100101001100 = 13194139238995
1011111111111111111111111011100000101001000000 = 824633702441
1011111111111111111111111011100000101011101000 = 6597069619549
Except for the first two there is a common definite pattern:
a leading 10, followed by a bunch of 1's, followed by 0111000001.
If the random numbers are random enough this seems to be
significant. I would like to see verification of the first
two numbers listed (perhaps a transcription error or some-such?).
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924098
home: bovenover 215, 1025 jn amsterdam, nederland; e-mail: d...@cwi.nl
Andreas Kaiser
> 1000111111111111111000110101111000010101000100 = 9895574626641
> 1010011111111111111101101101011000010010100000 = 1443107810341
> 1011111111111111111110111000001000110111101101 = 52776539295213
>
> Except for the first two there is a common definite pattern:
> a leading 10, followed by a bunch of 1's, followed by 0111000001.
> If the random numbers are random enough this seems to be
> significant. I would like to see verification of the first
> two numbers listed (perhaps a transcription error or some-such?).
No error of mine, but the results of these two numbers have a
significantly longer correct mantissa as the results of all others:
9895574626641
9.895574626641000e+12 = 402A8FFFE35E15100000
1.000000000000000e+00 = 3FFF8000000000000000
1.010552734661427e-13 = 3FD3E38E6622AB7F2614
9.999999999998295e-01 = 3FFEFFFFFFFFFFD00000
1443107810341
1.443107810341000e+12 = 4027A7FFF6D612800000
1.000000000000000e+00 = 3FFF8000000000000000
6.929489209567026e-13 = 3FD6C30C3B66AAA79320
9.999999999999858e-01 = 3FFEFFFFFFFFFFFC0000
On the random numbers: I have not the slightest idea about the quality
as they were created using a strange combination of two different
random number generators. I first tried to concatenate two successive
31-bit BSD random() results, but noticed that the resulting number
always was a multiple of 10000. So I combined both the standard 15-bit
rand() and the 31-bit random() of the EMX/GCC library (OS/2).
The intention of my program was to find out if there are other such
numbers, and how often they appear (which order of magnitude). Not to
find error patterns. Speed was premium (at ~2 hits per hour).
Additionally, I scanned all numbers 1..2^32-1 sequentially (~20min),
with just 1 hit (3221224323). I did not yet have the time to scan all
numbers 1..2^64-1 ;-).
Gruss, Andreas
PS: The program:
#include <stdio.h>
#include <stdlib.h>
#include <float.h>
#include <math.h>
#include <time.h>
main()
{
double x, y;
double c31 = (double) (1LL << 31);
double c15 = (double) (1LL << 15);
double c1 = 1.0;
double delta = 1e-15;
long long total = 0, error = 0;
setvbuf(stdout, NULL, _IOLBF, 80);
srand(time(NULL) & 0x7FFFFFFF);
srandom(time(NULL) & 0x7FFFFFFF);
x = 824633702441.0;
for (;;) {
++total;
if (((unsigned)total & (1024 * 1024 - 1)) == 0) {
fprintf(stderr, "\r%Ld %.0f ", total, x);
fflush(stderr);
}
y = (c1 / x) * x;
if (_fabsl(y - c1) > delta) {
++error;
fprintf(stderr, "\n%.0f: total=%Ld, error=%Ld\n", x, total, error);
printf("%.0f: total=%Ld, errors=%Ld\n", x, total, error);
}
x = (double) rand() * c31 + (double) random();
}
}
--------------------
-- Andreas Kaiser -- internet: a...@ananke.s.bawue.de
-------------------- fidonet: 2:246/8506.9
Roger N Wallace
>
>This appears to be a very serious hardware error in all Pentium chips.
>I do not see how anyone can use a Pentium for any numerical calculation
>that requires double precision. Imagine, for example, what might happen
>if this bug happened to occur during the inversion of a nearly singular
>matrix. Thus using Pentium PCs as workstation substitutes now appears
>to be impossible.
>
>I am anxiously waiting to hear when Intel will be releasing versions of
>the Pentium that correct this error and when they will be making them
>available to all those who currently own Pentium chips that give
>incorrect answers.
>--
>James G. MacKinnon Department of Economics
> phone: 613 545-2293 Queen's University
> Fax: 613 545-6668 Kingston, Ontario, Canada
>Internet: j...@qed.econ.queensu.ca K7L 3N6
The November 7 issue of the trade paper EETimes contains a page 1
story which describes the history of the FPU bug and of Intel's fix of the
problem. Summarizing the major points [my comments in brackets]:
1) Intel discovered the problem mid-year, and corrected it with a
revision of the on-chip programmable logic array. Pentium chips now shipping
are supposed to be free from the error. [There is, however, no guarantee
that a system or processor chip obtained today from distributor stock is
bug-free. No external markings specifically identify the "fixed" chips.
If the date of transfer to the fixed version at each Intel fab were
known, one _could_, in principle, decipher the date and factory location
codes printed on the chip package to determine whether it was made before
or after the "fix". Lacking this, the chip has to be tested in actual
computations to tell whether it is "good" or "bad".]
2) News of the bug reached the user community last week with the
re-posting on Compuserve of a private E-mail from Prof. (Mathematics) Thomas
Nicely of Lynchburg College (Virginia, USA) describing some specific
calculations which demonstrated erroneous results. [Subsequent findings have
been posted to this newsgroup.]
3) An Intel spokesman was quoted as saying that customers who had the
defective chips and were concerned about potential errors [We are] could
call, and Intel would arrange for replacements. There was no mention of an
associated charge or fee for the replacement chips.
=====
The way in which Intel will manage the chip replacements was not
announced in the article. I suspect that they will have to set up a special
"800" number or FAXBACK service through which users can arrange to exchange
existing chips. I would not be at all surprised to see some nominal "handling"
charge assessed for the exchange, although Intel might replace the chips at
no cost as an investment in customer "good will". As has been noted in this
newsgroup, virtually all Pentium systems now in the field have the bug. All
users who do extended-precision numerical calculations will certainly want
to swap. Some office automation users may not care about or need extended-
precision calculations and will not bother to swap. However, _if_ Intel
stands by the statement attributed to the unnamed "spokesman", they have
(worst case) just signed up to replace every Pentium processor shipped prior
to about 1 July 1994.
Roger Wallace
Terje Mathisen
>[nice summary of FDIV story deleted]
>
> The way in which Intel will manage the chip replacements was not
>announced in the article. I suspect that they will have to set up a special
>"800" number or FAXBACK service through which users can arrange to exchange
>existing chips. I would not be at all surprised to see some nominal "handling"
>charge assessed for the exchange, although Intel might replace the chips at
>no cost as an investment in customer "good will". As has been noted in this
>newsgroup, virtually all Pentium systems now in the field have the bug. All
>users who do extended-precision numerical calculations will certainly want
>to swap. Some office automation users may not care about or need extended-
>precision calculations and will not bother to swap. However, _if_ Intel
>stands by the statement attributed to the unnamed "spokesman", they have
>(worst case) just signed up to replace every Pentium processor shipped prior
>to about 1 July 1994.
>
a simple calculation shows me that it could cost them up 2.5 billion dollars.
I got that number by assuming that Intel are currently selling all the
p5's they can produce, at close to the announced $547 price. This is
obviously (hopefully?) a lot more than their marginal production cost, but
still valid if they could have gotten the full list price.
-Terje Mathisen (include std disclaimer) <Terje.M...@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
Francis Yom
>I'll write and post a minimal testing program, which will look for the
>bug and report back with the Pentium CPUID stepping info. Assuming that
>the fixed p5's have got a new stepping level, this program will find it.
Hi Terje,
I used your p87test.com to test my pentium 90 computer, and I discovered
that it has the FDIV bug!!
My question is who should I contact? Dell, the manufacturer, or Intel?
And which department (phone number?) should I speak to?
Thanks!
Fran
Doug Puchalski
>This appears to be a very serious hardware error in all Pentium chips.
>I do not see how anyone can use a Pentium for any numerical calculation
>that requires double precision. Imagine, for example, what might happen
>if this bug happened to occur during the inversion of a nearly singular
>matrix. Thus using Pentium PCs as workstation substitutes now appears
>to be impossible.
Just wait until missiles start crashing in off target, killing millions.
The last thing you'll see is that "Intel Inside" logo on the side of
the warhead.
Rana Mansour
: I am a firm beliver in giving vendors (both hardware and software) a really
: hard time when they mess up, but is this particularly obscure floating
: point nit really something that we should be brow beating Intel about?
Ron,
If I understand all this correctly - at some point Intel learned
of the problem, fixed it by midsummer, but continued to all allow
the distribution of chips that were known to be faulty. I think
that's something we should brow beat Intel about.
Jeff Beck via usg...@gsusgi2.gsu.edu
Dan Gezelter
Ronald F. Guilmette <r...@rahul.net> wrote:
>>In article <39rd03$r...@knot.queensu.ca>, James MacKinnon
<j...@doug.uucp> wrote:
>>>This appears to be a very serious hardware error in all Pentium chips.
>Oh come on now. Very serious? As another poster noted, you would have
>to have some mighty specialized code even to be able to NOTICE the problem.
Yeah. Like quantum scattering code, or fluid dynamics code, or really
long trajectories for protein chains. ANYONE who inverts large
matrices for a living is going to get burned by this bug eventually.
This makes the Pentium completely unacceptable for many scientific and
engineering applications.
Glad I didn't buy one.
--Dan
--
_________________________________________________________________________
Don't step on my blue suede .sig geze...@neon.cchem.berkeley.edu
-------------------------------------------------------------------------
James MacKinnon
previous posts have indicated. It appears to occur whenever the
numerator is a power of two (including 2^0 = 1) and for a large number
of different values of the denominator. In particular, the denominator
0.824633702441E+12 that was posted here is not an isolated one. The bug
also occurs for every whole number from 0.824633702430E+12 (and probably
lower) through 0.824633702449E+12 (but not for 0.824633702450E+12).
Some selected results follow:
numerator denominator ratio ratio * denominator
0.0625 0.8246337024310000E+12 0.7579122655661645E-13 0.6249999976716936E-01
0.1250 0.8246337024320000E+12 0.1515824531130491E-12 0.1249999995343387E+00
0.2500 0.8246337024330000E+12 0.3031649062257305E-12 0.2499999990686774E+00
0.5000 0.8246337024340000E+12 0.6063298124507258E-12 0.4999999981373549E+00
1.0000 0.8246337024370000E+12 0.1212659624897040E-11 0.9999999962747097E+00
2.0000 0.8246337024400000E+12 0.2425319249785257E-11 0.1999999992549419E+01
4.0000 0.8246337024420000E+12 0.4850638499558749E-11 0.3999999985098839E+01
8.0000 0.8246337024470000E+12 0.9701276999058676E-11 0.7999999970197678E+01
16.0000 0.8246337024490000E+12 0.1940255399807029E-10 0.1599999994039536E+02
3.0000 0.8246337024400000E+12 0.3637978888230413E-11 0.3000000000000000E+01
16.0000 0.8246337024500000E+12 0.1940255407032691E-10 0.1600000000000000E+02
Note that the divisions in the last two lines yield correct results.
All results were generated using Lahey F77l/EM-32, Version 5.1 on
a P-90 machine running DOS.
Similar results were obtained using gcc 2.6 on a different P-90 machine
running Linux. This is unquestionably not a compiler problem.
As expected, a 486DX2/66 yielded correct results in all cases.
This appears to be a very serious hardware error in all Pentium chips.
I do not see how anyone can use a Pentium for any numerical calculation
that requires double precision. Imagine, for example, what might happen
if this bug happened to occur during the inversion of a nearly singular
matrix. Thus using Pentium PCs as workstation substitutes now appears
to be impossible.
I am anxiously waiting to hear when Intel will be releasing versions of
Jon Jenkins
: I am anxiously waiting to hear when Intel will be releasing versions of
: the Pentium that correct this error and when they will be making them
: available to all those who currently own Pentium chips that give
: incorrect answers.
I wonder how much they will cost, I can't see them being free.
----------------------------------------------------------------------
Name: Dr Jon Jenkins
Location: Digital Equipment Corp, NaC,
Burnett Place, Research Park,
Bond University, Gold Coast
QLD, AUSTRALIA 4229
Phone: 61-75-75-0151
Fax: 61-75-75-0100
Internet: jenk...@ozy.dec.com
The opinions expressed above are entirely personal and do not
reflect the corporate policy of DEC or the opinions of DEC management.
-----------------------------------------------------------------------
Ronald F. Guilmette
Roger N Wallace <rwal...@world.std.com> wrote:
>In article <39rd03$r...@knot.queensu.ca>, James MacKinnon <j...@doug.uucp> wrote:
>>
>>This appears to be a very serious hardware error in all Pentium chips.
Oh come on now. Very serious? As another poster noted, you would have
to have some mighty specialized code even to be able to NOTICE the problem.
I am a firm beliver in giving vendors (both hardware and software) a really
hard time when they mess up, but is this particularly obscure floating
point nit really something that we should be brow beating Intel about?
> The way in which Intel will manage the chip replacements was not
>announced in the article. I suspect that they will have to set up a special
>"800" number or FAXBACK service through which users can arrange to exchange
>existing chips. I would not be at all surprised to see some nominal "handling"
>charge assessed for the exchange, although Intel might replace the chips at
>no cost as an investment in customer "good will". As has been noted in this
>newsgroup, virtually all Pentium systems now in the field have the bug. All
>users who do extended-precision numerical calculations will certainly want
>to swap. Some office automation users may not care about or need extended-
>precision calculations and will not bother to swap. However, _if_ Intel
>stands by the statement attributed to the unnamed "spokesman", they have
>(worst case) just signed up to replace every Pentium processor shipped prior
>to about 1 July 1994.
Worse case indeed! You assume that every single user of a Pentum will
NOTICE the problem, and that every single one of them will demand a
swap. Not bloody likely.
Now, returning to reality for a moment, I'd like to make an appeal to
those folks who have been good enough to document the bug here, on behalf
of those of us who _might_ just care enough to want a _fresh_ Pentium
when and if we are buying a new system.
Could someone please write up a minimalist C program which just prints
``Has FDIV bug'' or, alternatively, ``Doesn't have FVID bug.'', and then
compile it down to a .EXE file and then uuencode it and post it here?
At this point I feel quite sure that a lot of folks would be greatful
for that.
Thanks in advance.
--
-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- E-mail: r...@segfault.us.com ----------- Purveyors of Compiler Test ----
-------------------------------------------- Suites and Bullet-Proof Shoes -
Bruce Adler [Contractor]
Jon Jenkins <jenk...@oils.ozy.dec.com> wrote:
>James MacKinnon (j...@doug.uucp) wrote:
>
>: I am anxiously waiting to hear when Intel will be releasing versions of
>: the Pentium that correct this error and when they will be making them
>: available to all those who currently own Pentium chips that give
>: incorrect answers.
>
>I wonder how much they will cost, I can't see them being free.
IANAL (I am not a lawyer), but if it's true that Intel continued to sell
known defective parts with the *intent* to charge everyone additional
money at a later time for the good stuff wouldn't that have legal
ramifications? I know that in California there are real estate full
disclosure laws, I wonder if there are full disclosure laws for
silicon real estate?
James MacKinnon
In a previous article, referring to the Pentium FDIV bug, I wrote
>>This appears to be a very serious hardware error in all Pentium chips.
In response, Ron Guilmette (r...@segfault.us.com) wrote
> Oh come on now. Very serious? As another poster noted, you would have
> to have some mighty specialized code even to be able to NOTICE the problem.
I stand by my original statement (except that the "all" may no longer be
true; see below). It is undoubtedly true that many Pentium users will
not be affected by this bug. But anyone who does floating point
calculations for which it is necessary to use real*8 variables in Fortran,
or doubles in C, could be very seriously affected. I have lots of programs
which work just fine when certain variables are real*8 and produce garbage
when those variables are real*4. This bug means that, at some critical
point in one of my programs, such as when doing a pivot step in a matrix
inversion, a result that should be accurate to 15 digits may only be
accurate to 8 or so. I cannot possibly trust the results of such a program
if it is run on a buggy Pentium computer.
Several posters have reported that Intel claims to have fixed this bug in
recent versions of the Pentium. Can anyone independently verify this
claim? That is, has anyone run Terje Mathisen's test program on a
recently bought Pentium system and had it report that the bug is *not*
present? It is present in every Pentium that I have tested.
Frankly, I am very disappointed by the way Intel is responding to this
problem. Their public statements about how rare the problem is may seem
reasonable to people who know nothing about floating point calculations,
but they provide no reassurance at all to those of us who know something
about the issues, and they smack of deliberate disinformation.
Dell Canada, from whom we have bought two P-90 machines specifically for
doing number crunching, says that Intel has not yet come up with any way
for Dell to fix the machines it has sold. I have informed Dell that we
will not purchase any more Pentiums, from them or anyone else, until the
existing machines have been fixed and we can be assured that all new
machines operate correctly.
Roger N Wallace
>those folks who have been good enough to document the bug here, on behalf
>of those of us who _might_ just care enough to want a _fresh_ Pentium
>when and if we are buying a new system.
>
>Could someone please write up a minimalist C program which just prints
>``Has FDIV bug'' or, alternatively, ``Doesn't have FVID bug.'', and then
>compile it down to a .EXE file and then uuencode it and post it here?
>
Although written in assembler rather than C, the program p87test from
Terje Mathisen does what you request and a bit more. It was posted (both
source and executable) in a uuencoded ".zip" archive to this group
yesterday.
Roger Wallace
Larry Doolittle
: [chop] ... ANYONE who inverts large
: matrices for a living is going to get burned by this bug eventually.
: This makes the Pentium completely unacceptable for many scientific and
: engineering applications.
: Glad I didn't buy one.
Fix 1: replace your Pentium with a new one.
Fix 2: modify gcc to not use FDIV (call a subroutine, instead)
Note that most serious math is very light on FDIV, so speed is
not likely to be seriously affected. Heck, I don't even think
a Cray _has_ an FDIV. Consequently, anyone wanting to do some
massively parallel computing on Pentium-class machines might
want to give Intel a call. I bet they would be willing to offer
a very good price on these defective CPU's that people are about
to start returning in droves :-).
I can just see now how Linux Pentiums will boot up:
Testing Pentium FDIV bug: PRESENT!
Do not use this machine for double precison arithmetic!
- Larry Doolittle dool...@cebaf.gov
John Lazzaro
Larry Doolittle <dool...@cebaf.gov> wrote:
>
>Note that most serious math is very light on FDIV, so speed is
>not likely to be seriously affected.
From page A-26 of the standard textbook for computer architecture,
Computer Architecture -- A Quantitative Approach, Patterson and
Hennesey (appendix written by David Goldberg)
"As a general rule of thumb, division algorithms should try to reach a
speed that is about one-third of multiplication. One argument in favor
of this this rule is that there are real programs (some versions of
SPICE (a circuit analysis program)) where the ratio of division to
multiplication is 1:3."
---
1:3 does not sound like "very light" usage to me; SPICE is a popular
PC application with several different vendors selling their own
versions, so this example is directly relevent.
Jon Jenkins
: In article <39uv8e$s...@hustle.rahul.net>,
: Ronald F. Guilmette <r...@rahul.net> wrote:
: >>In article <39rd03$r...@knot.queensu.ca>, James MacKinnon
: <j...@doug.uucp> wrote:
: >>>This appears to be a very serious hardware error in all Pentium chips.
: >Oh come on now. Very serious? As another poster noted, you would have
: >to have some mighty specialized code even to be able to NOTICE the problem.
: Yeah. Like quantum scattering code, or fluid dynamics code, or really
: long trajectories for protein chains. ANYONE who inverts large
: matrices for a living is going to get burned by this bug eventually.
: This makes the Pentium completely unacceptable for many scientific and
: engineering applications.
Or Microwave circuit simulations which is what I bought the thing for ;-)
I was wondering why some of the benchmarks, although faster, gave differring
results in some circumstances. Intel will be getting a phone call on Monday
morning!!
Tom Kraljevic
>Or Microwave circuit simulations which is what I bought the thing for ;-)
>I was wondering why some of the benchmarks, although faster, gave differring
>results in some circumstances. Intel will be getting a phone call on Monday
>morning!!
If you use any transcendentals at all, the p5 is likely to give
different answers than previous generations. This is should not
come as a surprise. Answers on any one particular instruction
(sin, for instance) shouldn't be off by more than an ULP or two
though.
--tom
Jon Jenkins
: jenk...@oils.ozy.dec.com (Jon Jenkins) writes:
Yep I do and one other reason was the better transcendentals
of the Pentium. However, some of the differences are quite
marked. Some testing has revealed differences ranging from
FLT_MIN<differences<.1% compared to a 486DX266. Absolute
errors are hard to define in this system as there are many
transcendental calculations. But some plots appear to
have spikes where none did/should exist. Without using
an arbitrary precision calculator and reproducing a
system near convergence by hand it wil be difficult
to assess these.
The absolute magnitude of the errors encountered
will vary dramatically from application to application
and from instance to instance.
The point I think is that there
is a known problem and for those doing repetetive
extended maths in systems where convergence is
a regualr feature will, at least in some cases, not
get the "correct" answer, where "correct" is
intended to imply within the expected potential of
the hw and sw. How significant these effects will
be I am not in a position to comment on at this
stage.
Ian Fitchet
>Oh come on now. Very serious? As another poster noted, you would have
>to have some mighty specialized code even to be able to NOTICE the problem.
Right. Specialised as in *any* double precision arithmetic.
>Worse case indeed! You assume that every single user of a Pentum will
>NOTICE the problem, and that every single one of them will demand a
>swap. Not bloody likely.
No, but not to bother telling people is just a bit shite.
>Could someone please write up a minimalist C program which just prints
>``Has FDIV bug'' or, alternatively, ``Doesn't have FVID bug.'', and then
>compile it down to a .EXE file and then uuencode it and post it here?
#define C 824633702449.0
main()
{
printf("%.70f\n",C);
printf("%.70f\n",(C)/(C));
printf("%.70f\n",1.0/(1.0/C));
printf("%.70f\n",(1.0/C)*C);
}
line #3 should be the same as line #1, and line #4 should be 1.0, I get:
824633702449.0000000000000000000000000000000000000000000000000000000000000000000000
1.0000000000000000000000000000000000000000000000000000000000000000000000
824633705521.0000000000000000000000000000000000000000000000000000000000000000000000
0.9999999962747095905157834749843459576368331909179687500000000000000000
If you note, the last line (easiest to see the problem) loses
accuracy 9 digits along, ie single precision maths. Not much cop for
anything vaguely scientific.
--
Cheers,
Ian
-------------------------------------------------------------------------------
Ian Fitchet I.D.F...@fulcrum.co.uk
Fujitsu Fulcrum Telecommunications ltd., Fordrough Lane, Birmingham, B9 5FL
Larry Doolittle
: In article <Cz696...@murdoch.acc.Virginia.EDU>,
: Larry Doolittle <dool...@cebaf.gov> wrote:
: >
: >Note that most serious math is very light on FDIV, so speed is
: >not likely to be seriously affected.
[ by bypassing the FDIV bug in the compiler,
hence slowing down divides substantially ]
: From page A-26 of the standard textbook for computer architecture,
: Computer Architecture -- A Quantitative Approach, Patterson and
: Hennesey (appendix written by David Goldberg)
: "As a general rule of thumb, division algorithms should try to reach a
: speed that is about one-third of multiplication. One argument in favor
: of this this rule is that there are real programs (some versions of
: SPICE (a circuit analysis program)) where the ratio of division to
: multiplication is 1:3."
: ---
: 1:3 does not sound like "very light" usage to me; SPICE is a popular
: PC application with several different vendors selling their own
: versions, so this example is directly relevent.
Note that I said "most". Sure, and raytracers are probably heavy users of
trig functions. I still think most work (Finite elements, for instnace)
is very light on divides. Furthermore, if the authors of SPICE decided
that the speed of the divide got in their way, they would find a way
to recode their algorithms to use less of them. To me it's impressive
that all this difficult float (divides, sqrt, trig) gets done as flawlessly
as it does in hardware. That stuff is difficult enough to do in software.
The DSP chips (that take speed very seriously) leave it out, concentrating
on doing fast multiply/adds. The i860 is in this category. What is the
i860 ratio of divide:multiply?
- Larry Doolittle dool...@cebaf.gov
Ronald F. Guilmette
I don't think so.
You have to keep in mind that _any_ recall is a massively expensive
undertaking.
In the automotive business, if the gas tank may catch fire, they have a
recall. They DO NOT however recall thousands of units if the only flaw
is that the cigarette lighters don't work. (Most people these days are
non-smokers, so the vast majority of buyers would never even notice if
the cigarette lighters didn't work. Likewise for the FDIV bug.)
Terje Mathisen
I don't know who to contact at Intel to get a replacement, so please don't
post or email me if your p5 has the FDIV bug.
I wrote p87test in the hope that the first person to find a corrected p5
would post the info it shows (by using the CPUID opcode), i.e. at what
stepping level was the bug removed?
Michael Hermann
>Fix 1: replace your Pentium with a new one.
>Fix 2: modify gcc to not use FDIV (call a subroutine, instead)
Fix 3: modify gcc (or whatever compiler) to add an FMUL after each
FDIV and enter the subroutine if results do not match.
This will (almost) as fast as the FDIV alone, as the
subroutine has to be executed extremely infrequently.
Actually I would have thought of such a "fix" as a bad joke until
several years ago. But then a manufacturer, who shall remain unnamed,
and whose CPU has almost exactly the same problem (also infrequent
DIV-errors) suggested fix 3 with no sign of joking.
Compiler modifications are obviously a generally accepted method of
bug-fixing. This has happened for "GenuineIntel"-Bugs :)) as well as
for bugs of other manufacturers, like NS, Mips-licensees etc.A
However, this method fails if known bugs are not documented.
What I'm really wondering is, how will AMD/CyriW/NexGEN a react?
Until now, they had just the original implementation before designing
(or cloning) their chips, therefore it was easy to implement the
same bugs (like POPAD). However, now that they started design before
any pentia were available, they probably missed the FDIV-bug and
implemented only their own private set of bugs.
However, if they are really quick they might still add a bit/pin
to enable bug emulation in addition to the native bugs.
Mike
--
Dipl.-Ing. Michael Hermann m...@regent.e-technik.tu-muenchen.de
Lehrstuhl fuer Rechnergestuetztes Entwerfen, Postfach 202420
Technische Universitaet Muenchen 089/21053657
Jon Jenkins
: Dan Gezelter <geze...@neon.cchem.berkeley.edu> wrote:
: >In article <39uv8e$s...@hustle.rahul.net>,
: >Ronald F. Guilmette <r...@rahul.net> wrote:
: >
: >>>In article <39rd03$r...@knot.queensu.ca>, James MacKinnon
: ><j...@doug.uucp> wrote:
: As I said in a separate posting, please put up or shut up.
: Please name one person who has been materially affected by this exceedingly
: rare bug.
Obviously at least one person was affected, the discoverer of the bug!!
I think the point is (Intel are you listening !!!) Intel know exactly REPEAT LOUDLY
exactly the magnitude and the effect of this problem. Intel's responsibility in the
very least is to release this information to those who ask so that the
user is in a position to decide whether the bug will affect them or not. I
bought the Pentium to increase speed and precision (better transcendals) of a
Microwave cicruit simulation package. I'm not sure whether this bug will
affect this or not, I suspect it will be marginal in most cases but in
a few cases will be very significant. What I need from Intel, who must know
this information, is the exact nature and magnitude of this problem.
I dont think any reasonable engineer will "hate" Intel for making a mistake,
we all make them, in this case the scale of the Pentium
product may make that an expensive mistake. What I think will raise
peoples ire is either arrogance or avoidance of the issue.
Intel should provide information on the exact nature of the problems
and the scale of the effect i.e. every mantissa with bit pattern of
0111110000001111 etc will only be divided with an accuracy of
x digits. If necessary then a user may have tu justify his/her
requirement for a replacement based upon either demonstrable problems
or a demonstrated use which will have a high probability of
significant effect i.e. scientific and engineering applications.
Hank Oredson
Sure.
Just as in the real estate case, you don't make any fuss
if you find a tiny scratch in one corner of an attic window.
Note that most of the "the world has come to an end because
there exist P5 chips which produce inaccurate results for
certain operations" posts have come from .edu sites?
Get a grip folks ... this is NOT a major big deal, except
perhaps to a couple dozen research folks working in obscure
areas of mathematics.
It will make NO difference when you are playing DOOM, doing
simulation modelling, using your favorite spreadsheet, etc.
In the real world, mission critical and life critical results
are actually *checked* before use ... unless of course you
are manufactuing mirrors for space based telescopes ...
... Hank
--
Hank Oredson @ Mentor Graphics Library Operations
Internet : hank_o...@mentorg.com "Parts 'R Us!"
Amateur Radio: W0...@W0RLI.OR.USA.NOAM
Peter Kim
>>
>>In a previous article, referring to the Pentium FDIV bug, I wrote
>>
>>>>This appears to be a very serious hardware error in all Pentium chips.
>>
>>In response, Ron Guilmette (r...@segfault.us.com) wrote
>>
>>> Oh come on now. Very serious? As another poster noted, you would have
>>> to have some mighty specialized code even to be able to NOTICE the problem.
>>
>>I stand by my original statement (except that the "all" may no longer be
>>true; see below). It is undoubtedly true that many Pentium users will
>>not be affected by this bug.
>
>
>>But anyone who does floating point
>>calculations for which it is necessary to use real*8 variables in Fortran,
>>or doubles in C, could be very seriously affected. I have lots of programs
>>which work just fine when certain variables are real*8 and produce garbage
>>when those variables are real*4. This bug means that, at some critical
>>point in one of my programs, such as when doing a pivot step in a matrix
>>inversion, a result that should be accurate to 15 digits may only be
>
>Wait a minute. Let me get out the violin. You're breaking my heart.
>
>-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
>---- E-mail: r...@segfault.us.com ----------- Purveyors of Compiler Test ----
>-------------------------------------------- Suites and Bullet-Proof Shoes -
Very impressive debating skill indeed Mr. Guilmette.
Here's how to 'kill' an author out of your trn reader:
o in thread selection mode, press control-k
o add the line '/author/f:j'
o save the file, and you will never have to read any more posts from
the author..
example KILL file:
/@intel.com/f:j
/r...@rahul.net/f:j
/r...@segfault.us.com/f:j
Good day.
Ronald F. Guilmette
Hank Oredson <Hank_O...@mentorg.com> wrote:
>
>Note that most of the "the world has come to an end because
>there exist P5 chips which produce inaccurate results for
>certain operations" posts have come from .edu sites?
Yes. I _did_ notice that!
Academics! Can't live with 'em. Can't kill 'em.
hummmph.
--
Steve Masticola
//Could someone please write up a minimalist C program which just prints
//``Has FDIV bug'' or, alternatively, ``Doesn't have FVID bug.'', and then
//compile it down to a .EXE file and then uuencode it and post it here?
/#define C 824633702449.0
/main()
/{
/ printf("%.70f\n",C);
/ printf("%.70f\n",(C)/(C));
/ printf("%.70f\n",1.0/(1.0/C));
/ printf("%.70f\n",(1.0/C)*C);
/}
The results of this test are compiler-dependent and may not show the
bug. A "no bug" result should be verified with Terje Mathisen's
p87test.com program. I tried the C program (using gcc under Linux) and
got no indication of the bug. Terje's program showed it.
My best guess is that my gcc installation either wasn't using the
floating-point processor, or was assuming real (as opposed to double
precision) numbers, or introduced enough error in the character
conversions to hide the bug. I might play with it a little tonight.
- Steve (mast...@scr.siemens.com).
Peter C. Murray
Hank Oredson (ha...@wv.mentorg.com) wrote:
[...]
: It will make NO difference when you are playing DOOM, doing
Yes it will. How can you happily play DOOM knowing that this evil
little FP bug is lurking evily somewhere inside your new pentium
system?? How can you sleep at night knowing that Intel knew
about this bug for the last 50 years and yet failed to inform
us and so divert the destruction of the world as we know it??!?
And where does Bill Gates fit into this whole satanic
conspiracy?? Inquiring minds have to know!
Ronald F. Guilmette
>Ronald F. Guilmette <r...@rahul.net> wrote:
>
>>>In article <39rd03$r...@knot.queensu.ca>, James MacKinnon
><j...@doug.uucp> wrote:
>
>>>>This appears to be a very serious hardware error in all Pentium chips.
>
>>Oh come on now. Very serious? As another poster noted, you would have
>>to have some mighty specialized code even to be able to NOTICE the problem.
>
>Yeah. Like quantum scattering code, or fluid dynamics code, or really
>long trajectories for protein chains. ANYONE who inverts large
>matrices for a living is going to get burned by this bug eventually.
>This makes the Pentium completely unacceptable for many scientific and
>engineering applications.
As I said in a separate posting, please put up or shut up.
Please name one person who has been materially affected by this exceedingly
rare bug.
--
Ronald F. Guilmette
>
>In a previous article, referring to the Pentium FDIV bug, I wrote
>
>>>This appears to be a very serious hardware error in all Pentium chips.
>
>In response, Ron Guilmette (r...@segfault.us.com) wrote
>
>> Oh come on now. Very serious? As another poster noted, you would have
>> to have some mighty specialized code even to be able to NOTICE the problem.
>
>I stand by my original statement (except that the "all" may no longer be
>true; see below). It is undoubtedly true that many Pentium users will
>not be affected by this bug.
Fine. Name me one person who WILL BE affected.
>But anyone who does floating point
>calculations for which it is necessary to use real*8 variables in Fortran,
>or doubles in C, could be very seriously affected. I have lots of programs
>which work just fine when certain variables are real*8 and produce garbage
>when those variables are real*4. This bug means that, at some critical
>point in one of my programs, such as when doing a pivot step in a matrix
>inversion, a result that should be accurate to 15 digits may only be
>accurate to 8 or so...
Wait a minute. Let me get out the violin. You're breaking my heart.
--
Marco van den Boogaard
>i...@fulcrum.co.uk (Ian Fitchet) writes:
>//Could someone please write up a minimalist C program which just prints
>//``Has FDIV bug'' or, alternatively, ``Doesn't have FVID bug.'', and then
>//compile it down to a .EXE file and then uuencode it and post it here?
>/#define C 824633702449.0
>/main()
>/{
>/ printf("%.70f\n",C);
>/ printf("%.70f\n",(C)/(C));
>/ printf("%.70f\n",1.0/(1.0/C));
>/ printf("%.70f\n",(1.0/C)*C);
>/}
>The results of this test are compiler-dependent and may not show the
>bug. A "no bug" result should be verified with Terje Mathisen's
>p87test.com program. I tried the C program (using gcc under Linux) and
>got no indication of the bug. Terje's program showed it.
It's the same story for me: I've got both SM-D*S and Linux running, and I didn't get any indication
of the bug when I compiled this program with gcc 2.5.8, either, though p87test.com under D*S really
thought something was wrong.
>My best guess is that my gcc installation either wasn't using the
>floating-point processor, or was assuming real (as opposed to double
>precision) numbers, or introduced enough error in the character
>conversions to hide the bug. I might play with it a little tonight.
Yeah, if you want to use a C program to find such a bug, you explicitly have to tell C to use
doubles, or else you don't know what kind of floats it will use
>- Steve (mast...@scr.siemens.com).
Marco
--
|\/| Marco van den Boogaard | It's nice to be
_| _| marc...@sci.kun.nl | slightly crazy
|/|), University of Nijmegen | (== weird)
|) |
Christian Gross
You know what you are saying is a joke. Many people
will calculate without knowing any better. The reason
is that some calculations are so diverse that there really
is no reason to check, as they have checked the usual.
So when the bug does appear people will not be any of the wiser.
And to think most people play doom is ridiculous. I bought
my Pentium to do work, and that error does explain a few things.
The reason I have not thought of the Pentium chip is that I
thought these sort of bugs did not occur.
Christian
Marco van den Boogaard
>Yo, real people who do all natures of real calcs are out here and care.
>Don't trivialize. I'm just glad I learned about this before I had any
>major calcs to report. You see, even the person checking my calc might
>be using a pentium, and create what we nuclear types call a common mode
>failure......
Well, if this isn't a good example of what can happen. All people who say it's not bad for playing
doom: that's a lousy argument, since you don't buy a rather expensive Pentium computer just to play
this game. If you only want to play games, you buy a Nintendo or a Sega, not a Pentium that's more
then ten times the price.
Buying a Pentium for games is as inmature as buying an expensive internet-account just because it
enables you to read alt.binaries.pictures.erotica* and do nothing more.
Let's get real: I don't mind if people say most people won't ever have a confrontation with the
bug, but don't get any GAMES into the discussion, 'cause that is degrading the whole status of the
Pentium: it was not meant to play games on(I'm sure), it's just possible because pentiums have to
be compatible with 486/386 machines, on which there _are_ a lot of games.
I really think Intel should have told institutes which are doing important things on computers
(maybe pentiums, maybe not, just tell them all to make sure) that the bug exists, and not keep
their mouth shut. It's potentially dangerous (like MIT Crook tells us).
>Ed
Roger N Wallace
Terje Mathisen <Terje.M...@hda.hydro.com> wrote:
>In <39ttbe$i...@nova.umd.edu>, fy...@nova.umd.edu (Francis Yom) writes:
>>
>>I used your p87test.com to test my pentium 90 computer, and I discovered
>>that it has the FDIV bug!!
>>
>>My question is who should I contact? Dell, the manufacturer, or Intel?
>>And which department (phone number?) should I speak to?
>>
>
>I don't know who to contact at Intel to get a replacement, so please don't
>post or email me if your p5 has the FDIV bug.
>
Checking the directory at acavax.lynchburg.edu mentioned by Thomas Nicely in
his original mail about the bug, I found the following file, pentium.doc:
----
Information regarding the Pentium processor and FPU may be obtained by
calling Intel at 800-628-8686, or by contacting Intel representative
John Thompson at 408-765-1279.
----
I'll hazard a guess that these numbers will be rather busy on Monday.
Roger Wallace
Steve Platt
[snip]
>>Could someone please write up a minimalist C program which just prints
>>``Has FDIV bug'' or, alternatively, ``Doesn't have FVID bug.'', and then
>>compile it down to a .EXE file and then uuencode it and post it here?
>#define C 824633702449.0
>main()
>{
> printf("%.70f\n",C);
> printf("%.70f\n",(C)/(C));
> printf("%.70f\n",1.0/(1.0/C));
> printf("%.70f\n",(1.0/C)*C);
>}
...beware of the optimizer which reduces your code -- you may find
*all* of your divisions disappearing!
Steve Platt
>In <CzBJB...@scr.siemens.com> mast...@scr.siemens.com (Steve Masticola) writes:
>>i...@fulcrum.co.uk (Ian Fitchet) writes:
>>//Could someone please write up a minimalist C program which just prints
>>//``Has FDIV bug'' or, alternatively, ``Doesn't have FVID bug.'', and then
>>//compile it down to a .EXE file and then uuencode it and post it here?
>>/#define C 824633702449.0
>>/main()
>>/{
>>/ printf("%.70f\n",C);
>>/ printf("%.70f\n",(C)/(C));
>>/ printf("%.70f\n",1.0/(1.0/C));
>>/ printf("%.70f\n",(1.0/C)*C);
>>/}
>>The results of this test are compiler-dependent and may not show the
>>bug. A "no bug" result should be verified with Terje Mathisen's
>>p87test.com program. I tried the C program (using gcc under Linux) and
>>got no indication of the bug. Terje's program showed it.
[big-time snip]
A followup to an earlier post I made concerning optimization stripping
away your divides. I just checked the asm output from Microsoft
Visual C++/NT v. 1.5. Effectively, it reduces to
printf("...", C);
printf("...", 1.0);
printf("...", C);
printf("...", 1.0);
even when all optimizations are disabled (debug mode)!
I would guess gcc and most other compilers (any smarter than a
third-year undergrad would produce for a compiler course)
will automatically simplify those constant expressions.
A workaround which should work: write an external function
"double f(double a) { return(a); }". Place
in a different file (hide it from the compiler). Replace
the statements with things like
printf("...", f(C)/f(C));
As I remember, constants in C default to long floats, so
f(1.0) will suffice.
I just tested under MSVC++ -- it is now generating FDIVs
nicely. Time to find a pentium.
-Steve
Royden Yates
me that the som...@x.intel..... folk have been conspicuous by their absence.
Hell, some weeks ago one could'nt whisper a negative word without some
rejoinder from "not an official spokeperson for Intel". Where are you chaps?
Or is the FDIV bug not something about which you are allowed to hold
'unofficial' opinion?
Duane Mattern (NYMA)
I suggest you all call the Intel Customer Service line at 1-800-628-8686.
Use your touch tone phone to get to the microprocessor techicial help
desk and register a complaint.
I called and talked to Helen. SHE stated that Intel does not know
who at Intel did the interview and that Intel has no plans to replace
microprocessor. She stated that the problem is way over blown and
that Intel claims that users would only see an error once every 27 years
or an error rate of 1 in 9 billion. I told Helen that Intel better
make an announcement on the InterNet soon or they'd have big publicity
problem on their hands.
Our branch at NASA Lewis Research Center just bought 9 EPS 90MHZ Pentium
PC workstation. All of these machines have the problem indicated using
p87test.com. We use these machine for research on air breathing
propulsion system, (simulations and control system designs), using
software tools like the MathWorks MATLAB and ISI's MatrixX, all using
double precision calculations. I'd feel more comfortable knowing
my computer is not introducing and errors into my calculations. If
Intel announces that any error generated is only 1e-17 or some small
number, then I could live with that, but I want to hear it from Intel.
Duane Mattern (mat...@ariel.lerc.nasa.gov)
MIT Crook
Yo, real people who do all natures of real calcs are out here and care.
Don't trivialize. I'm just glad I learned about this before I had any
major calcs to report. You see, even the person checking my calc might
be using a pentium, and create what we nuclear types call a common mode
failure......
Ed
Andrew M. Gough
> In article <39uv8e$s...@hustle.rahul.net>,
>
> | Oh come on now. Very serious? As another poster noted, you would have
> | to have some mighty specialized code even to be able to NOTICE the problem.
> |
> | hard time when they mess up, but is this particularly obscure floating
> | point nit really something that we should be brow beating Intel about?
>
> hogwash! A CPU which gives incorrect results for operations with certain
> initial values is about as useful as a car with brakes which fail at
> certain intersections.
I would urge you to use more specific language when discussing this.
I, for one, would not consider the results "incorrect," because they
are accurate, but with lower precision. To me, correctness = accurate.
Precision is how finely divided your measurement is.
So your analogy is not analogous. A better one would be "as useful
as a car with brakes which change the stopping distance by one
picometer at certain intersections."
>
> Just when I was kicking myself for buying a DX2-80...
Resume kicking. ;-)
Regards,
Andy
Disclaimer:
All views expressed are my own opinions, and not necessarily
those of Intel Corporation.
_______________________________________________________________________________
Andy Gough | Internet: andrew_...@ccm.ch.intel.com
Intel Corporation CH5-131 | ICBM : 111^55'42" W; 33^18'23" N
5000 W. Chandler Blvd. | "Knowledge is power."
Chandler, AZ 85226 | -- Francis Bacon
-------------------------------------------------------------------------------
Steve Masticola
pl...@cs.swarthmore.edu (Steve Platt) writes:
[ Compiler artifacts, including optimization and type assumptions, hid
FDIV bug in short C program test ]
Another data point: Once I forced the constants to be double
precision, the program showed the bug fine. (gcc under linux was used
to compile.)
#define C 824633702449.0L
main()
{
printf("%.70f\n",C);
printf("%.70f\n",(C)/(C));
printf("%.70f\n",1.0L/(1.0L/C));
printf("%.70f\n",(1.0L/C)*C);
}
You may want to set the appropriate compiler options to force
optimization off (-g usually does this) and force the use of HW
floating point on.
- Steve (mast...@scr.siemens.com)
Robert W. Igo
So I can (and will, now that the occasion has presented itself) stand up
here and tell you as loudly and clearly as I can that all of you folks who
are going on and on, and pissing in your pants about the Pentium FDIV bug
are being nothing less than outrageously silly, because you are only looking
at (and worrying about) the tiny tip of a very very large iceberg.
***
Ronald. Software bugs can be fixed with a patch or a new version of the
software. Usually free or relatively cheap for registered users. *Firmware*
bugs must be replaced, or else a software workaround needs to be done in all
applications which would encounter the bug.
I think what has people so upset about the Pentium bug is that you can't just
grab a 10k patch file from your local ftp site to fix the bug. Since Intel is
being quiet about their policy (assuming they have one) then no one knows what
they intend to really do about their (our) problem.
And programmers aren't the only ones who use computers, so your compiler
argument isn't as strong as it could be. Of course, someone had to use a
compiler to write the software people are using, but if the end-user finds a
bug, they shouldn't care where the bug came from, even if it was from a nasty
compiler. As far as a user (and customer) is concerned, the bug should be
reported and fixed. If the software company refuses to do that, then the
customer may decide to return the software for a refund, since it didn't suit
their needs. It's not quite so easy to return your CPU if it doesn't suit your
needs.
[********************************* Bob Igo ********************************]
"Now let me explain why this makes intuitive sense." --Prof. Larry Wasserman
[***************************** gryp...@cmu.edu ***************************]
Andrew J. L. Cary
>From: jhe...@netcom.com (John Hesse)
>Subject: Re: FDIV bug in Pentium chips!
>Date: Thu, 17 Nov 1994 02:52:56 GMT
>In article <3a5o64$o...@hustle.rahul.net>,
>Ronald F. Guilmette <r...@rahul.net> wrote:
>>In article <3a0b2r$j...@agate.berkeley.edu>,
>>
>>As I said in a separate posting, please put up or shut up.
>>
>>Please name one person who has been materially affected by this exceedingly
>>rare bug.
>>
>O. J. Simpson, you ninny. Don't you ever read the news?
>--
> - - - - - - - - - - - - - - -
>John Hesse
>Moss Beach, Calif
>jhe...@netcom.com
> - - - - - - - - - - - - - - -
Boy is this getting dreary.
In answer to the plea:
Please name one person who has been materially affected by this exceedingly
rare bug?
Me and my company. We exist in a very regulated environment with extremely
complex and thorough system validation rules. As a result of these rules we
cannot use PENTIUM based PCs to prepare submissions for regulatory agencies
until Intel replaces the CPU chips. You can't use computational results
from a system with a known hardware/software bug unless you verify the results
by cross checking the results with one without the bug. This effectively
doubles the work. So we just moved all critical production work off of the
Pentiums which fail the P78TEST.COM. So far this has been all of our Pentium
based machines.
I recognize this is not a technical reason, but it has the same effect for us
as if it was.
---------------------------------------------------------------------------
Andrew J L Cary, Senior Curmudgeon : In general, these are my opinions &
CBDM, Development Research : do not reflect those of my employers
Syntex (USA) Inc, Palo Alto, CA 94301: they ARE welcome to use them
---------------------------------------------------------------------------
Peter Kim
>>| Ronald F. Guilmette <r...@rahul.net> wrote:
>>
>>| >Wait a minute. Let me get out the violin. You're breaking my heart.
>>
>
>here and tell you as loudly and clearly as I can that all of you folks who
>are going on and on, and pissing in your pants about the Pentium FDIV bug
>are being nothing less than outrageously silly, because you are only looking
>at (and worrying about) the tiny tip of a very very large iceberg.
>
Ron, it is ironic how you use the iceberg analogy. The fact that _you_
can only see the tip of the iceberg is troubling. As many people have
stated, there is no real good workaround for the FPU problem. What would
you say to the Mathworks president who posted about this problem in Pentium?
"fix your damn MATLAB software to work around the FPU bug!"? Your attitude
toward this reminds me of a couple of jokes I've seen on rec.humor:
Q:How many Microsoft executives does it take to screw in a lightbulb?
A:Zero, they change the standard to darkness!
Q:How many Intel executives does it take to screw in a lightbulb?
A:One, he will hold the lightbulb to the socket and wait until the world
revolves around.
The point is, you have to go out and fix every piece of software
ever published that takes advantage of FDIV function! There seems to be
two points on this matter that you simply donot understand:
point 1
The World: FDIV bug has a far reaching implications to my work on a Pentium.
Ron: The problem associated with FDIV has extremely small chance of
occurance, therefore it is no big deal.
point 2
The World: I want my Pentium replaced with a 'good' Pentium.
Ron: Let me get out the violin, you're breaking my heart!
Put up or shut up! Why don't you go out and beat on
a software company instead of my precious Intel?
The flaw with your defense on point one is fairly easy to show -
the chance of bug occurance is per instruction, per hour, per week, or per
what??? Okay, let's say that the Intel's figure of 10**-10 is a per
instruction chance. These processors are made to execute millions of
instructions per second. If you know anything about statistics, then
you'd realize that you have compounding probability of the bug occurance.
Given an everage lifetime of a computer, the computer _will_ run into
the FPU bug with a high probablity. The error magnitude will vary
depending on a type of calculation, but for some it _will_ be very
important. And if you know anything about error propagation, you wouldn't
be making such ignorant remarks. As for your response to the second point,
I can only say one thing : take a logic class. If a customer paid up to
$1000 for a piece of silicon, I think they deserve either a refund or a fix
to the problem. In this case, the 'fix' turns out to be a replacement. It
looks grim for Intel who may have to replace a large number of silicons, but
they should have accounted for bugs like this in their profit. Medical
doctors pay tons of money to cover for the Malpractice insurance (a cover
for a potential mistake they will make). Intel knows better, they've made
mistakes like this before. We're all human, we all make mistakes. It is
how we take the responsibility that will separate us from animals.
Ron, I'm sick of hearing your ignorant remarks on this subject. With
respect (you probably have talents elsewhere), shut the @#%& up!
- Peter
Paul Rubin
Andrew M. Gough <andrew_...@ccm.ch.intel.com> wrote:
>In article <3aavg5$9...@usenety1.news.prodigy.com>, bill davidsen writes:
>I would urge you to use more specific language when discussing this.
>I, for one, would not consider the results "incorrect," because they
>are accurate, but with lower precision. To me, correctness = accurate.
>Precision is how finely divided your measurement is.
Excuse me, but "correct" in this case means "does what the spec says"
where the spec is IEEE 754. The results are incorrect. The spec
says what each of the 64 bits of the result is supposed to be.
The Pentium gets half of them wrong.
bill davidsen
Jon Jenkins <jenk...@oils.ozy.dec.com> wrote:
| Yep I do and one other reason was the better transcendentals
| of the Pentium. However, some of the differences are quite
| marked. Some testing has revealed differences ranging from
| FLT_MIN<differences<.1% compared to a 486DX266. Absolute
| errors are hard to define in this system as there are many
| transcendental calculations. But some plots appear to
| have spikes where none did/should exist. Without using
| an arbitrary precision calculator and reproducing a
| system near convergence by hand it wil be difficult
| to assess these.
You could run your codes on a recent Pentium and see if the spikes go
away. At least you didn't write your doctoral thesis based on explaining
the spikes, or have it rejected because you couldn't.
--
Bill Davidsen (davi...@tmr.com) UNIX Codger
Will solve problems for money.
Stupidity, like virtue, is its own reward.
bill davidsen
Marc A. Murison <mur...@cfa.harvard.edu> wrote:
| Or ray tracing where you're worried about sub-picometer path length errors.
| I, too, was wondering why the hell I was getting different answers on my brand
| spankin' new hot-snot P5-90....
|
| Or long celestial mechanics orbit calculations...Or...the list goes on.
I can't believe that Intel didn't publicise this ASAP. While they
certainly are not liable for having a bug in their chip, I would suspect
that they would be liable if they didn't make every effort to publicise
the problem.
Any reader of gun magazines knows that if the slightest defect is
discovered in a gun, the manufacturer immediately puts ads in the
various magazines to alert the public and avoid liability by "best
effort." By keeping this a secret and not marking the chips, Intel
certainly gives the appearances of concealment.
Lot of talk a while ago about the new 4x superscalars coming, now thay
have a slogan "our integer is faster and our floating point works."
Marc A. Murison
>Dan Gezelter (geze...@neon.cchem.berkeley.edu) wrote:
>: Ronald F. Guilmette <r...@rahul.net> wrote:
>: <j...@doug.uucp> wrote:
>: >>>This appears to be a very serious hardware error in all Pentium chips.
>: >Oh come on now. Very serious? As another poster noted, you would have
>: >to have some mighty specialized code even to be able to NOTICE the problem.
>: long trajectories for protein chains. ANYONE who inverts large
>: matrices for a living is going to get burned by this bug eventually.
>: This makes the Pentium completely unacceptable for many scientific and
>: engineering applications.
>I was wondering why some of the benchmarks, although faster, gave differring
>results in some circumstances. Intel will be getting a phone call on Monday
>morning!!
Or ray tracing where you're worried about sub-picometer path length errors.
I, too, was wondering why the hell I was getting different answers on my brand
spankin' new hot-snot P5-90....
Or long celestial mechanics orbit calculations...Or...the list goes on.
---------------------------------------------------------------------
| Marc A. Murison | Smithsonian Astrophysical Observatory |
| mur...@cfa.harvard.edu | 60 Garden Street, MS 63 |
| (617) 495-7079 | Cambridge, MA 02138 |
---------------------------------------------------------------------
Paul Rubin
>small firmware bug had even a remote idea how many bugs most of your
>COMPILERS have in them (many of which are far more serious than this)
>you would quickly forget all about Intel and start panicking about your
>compiler vendors instead.
Most people are not complaining that the very complex Pentium
cpu turned out to have a bug, but that Intel knew about the
bug for several months yet kept it secret.
The compiler I use also has bugs, but they are not secret.
Bugs are reported to an internet address (bug...@gnu.ai.mit.edu)
and if I want to find out about every bug as soon as it is
discovered, I can just write bug-gcc...@gnu.ai.mit.edu
and ask to be added to the list. Then I would receive all
the bug reports at the same time as the maintainers.
If there was a bug-p...@intel.com that anyone could join by
emailing to bug-penti...@intel.com, I'd have a lot more
sympathy for Intel. The same goes for all other hardware and software
vendors that keep their bug reports secret because they don't want to
blemish the myth of perfection that their marketroids try to foist off
on us.
If I have to redo a calculation because of a compiler or cpu bug that
no one previously knew about, that's unfortunate but unavoidable. If
I have to redo it because of a bug that the compiler or chip vendor
knew about but kept secret for marketing reasons, that is unnecessary
work that I should be able to bill the vendor for.
bill davidsen
| >>when those variables are real*4. This bug means that, at some critical
| >>point in one of my programs, such as when doing a pivot step in a matrix
| >>inversion, a result that should be accurate to 15 digits may only be
| >>accurate to 8 or so...
| >
| >Wait a minute. Let me get out the violin. You're breaking my heart.
| >
| >-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
| >---- E-mail: r...@segfault.us.com ----------- Purveyors of Compiler Test ----
| >-------------------------------------------- Suites and Bullet-Proof Shoes -
If this person has the same "it won't effect many people" attitude about
testing compiler that he has about CPUs, I certainly will let someone
else "purvey" my test suites.
This is not like a sort which, every once in a while, takes a long time
when the numbers are in some unlikely order, this is like a sort which,
every once in a while, doesn't put the output in order at all. Anyone
who is willing to accept a CPU (or compiler) which just plain doesn't
work from time to time should be doing something other than QA!
Barry Clarke
>Well, if this isn't a good example of what can happen. All people who say it's not bad for playing
>doom: that's a lousy argument, since you don't buy a rather expensive Pentium computer just to play
>this game. If you only want to play games, you buy a Nintendo or a Sega, not a Pentium that's more
>then ten times the price.
>
>Buying a Pentium for games is as inmature as buying an expensive internet-account just because it
>enables you to read alt.binaries.pictures.erotica* and do nothing more.
>
>Let's get real: I don't mind if people say most people won't ever have a confrontation with the
>bug, but don't get any GAMES into the discussion, 'cause that is degrading the whole status of the
>Pentium: it was not meant to play games on(I'm sure), it's just possible because pentiums have to
>be compatible with 486/386 machines, on which there _are_ a lot of games.
Excuse me, have you actually seen Intel's advertising campaign???? They are selling
the Pentium as _the_ chip to play games on, all the leisure mags such as PC Format
are plugging the Pentium... and yes people do buy Pentiums to play games on - Try
playing Wing Commander III on anything less than a P90 and it's a bit crap actually.
Barry.
Paul Rubin
Duane Mattern (NYMA) <mat...@ariel.lerc.nasa.gov> wrote:
>I called and talked to Helen. SHE stated that Intel does not know
>who at Intel did the interview and that Intel has no plans to replace
>microprocessor. She stated that the problem is way over blown and
>that Intel claims that users would only see an error once every 27 years
>or an error rate of 1 in 9 billion. I told Helen that Intel better
>make an announcement on the InterNet soon or they'd have big publicity
>problem on their hands.
I don't know how many cycles a Pentium FDIV takes, but say it is
100 cycles (hopefully it is really a lot less). Then 9 billion
FDIV's takes 900 billion cycles. At 90 MHz, that is 10000 seconds
per FDIV error, or about 3 hours, not 27 years. I wonder where
they got that 27 year figure from. Maybe they did the calculation
on a Pentium :-)
Andrew Wilks
>It is precisely _because_ I test compilers for a living (and BECAUSE I know
>at least as well as anyone here how buggy most of THEM are) that all of
>this ranting and raving about one tiny little firmware glitch seems like
>a lot of worrying about the arrangement of the deck chairs on the Titanic.
>I have a simple suggestion for you all. Why don't you all take just 10%
>of the energy that you are now devoting to beating Intel about the head
>and neck over this one small slip up and devote it instead to finding out
>how well your respective compiler vendors are doing _their_ QA (relative
>to Intel and _its_ QA)? Ask them how much they have spent on test suites
>relative to their compiler sales.
>I really _would_ like to know what it is about human psychology that causes
>people to get totally up in arms about a small firmware glitch (like this
>FDIV thing) while they merely yawn at the prospect of DOZENS of serious
>bugs in their compilers.
>
>If any of you out there are psychology majors, and if you can explain this
>to me, please do. I must confess, it's an enigma to me.
There was a special on PBS a while ago about percieved risks vs. real risks.
People that were deathly afraid of flying would hop in their cars with no
seat belts althought the actual risk of dying in an auto wreck without a
seatbelt is orders of magnitude greater than dying in a plane crash. It
supposedly boils down to whether you feel "in control" or not.
I wonder if there is a hardware vs. software connection here that is related?
Personally, I fly, wear my seatbelt while driving and do math on my pentium.
I don't cross the street without looking both ways or insult Mr. T face to
face.
Andy
Hiroshi
for purchase condition and if the system fails to meet this, you can
get money back.......
John F Carr
Hiroshi <hir...@cgate.hipecs.hokudai.ac.jp> wrote:
Because the IEEE standard requires software support that condition is
not useful unless you get the hardware and software suppliers to agree.
The Pentium hardware bug can be worked around in software so it is still
possible for a Pentium system to conform to the IEEE standard (you
don't need a FPA at all to support IEEE FP, it just runs slower if you
do it in software).
--
John Carr (j...@mit.edu)
K.H. Lee
Adler [Contractor]) writes:
|> Jon Jenkins <jenk...@oils.ozy.dec.com> wrote:
|> >James MacKinnon (j...@doug.uucp) wrote:
|> >
|> >: I am anxiously waiting to hear when Intel will be releasing versions
|> of
|> >: the Pentium that correct this error and when they will be making
|> them
|> >: available to all those who currently own Pentium chips that give
|> >: incorrect answers.
|> >
|> >I wonder how much they will cost, I can't see them being free.
|>
|> IANAL (I am not a lawyer), but if it's true that Intel continued to sell
|> |> known defective parts with the *intent* to charge everyone additional
|> |> money at a later time for the good stuff wouldn't that have legal
|> ramifications? I know that in California there are real estate full
|> disclosure laws, I wonder if there are full disclosure laws for
|> silicon real estate?
--
name : Kuek Hock Lee
place : Silicon Graphics Inc.
uucp : kh...@mti.sgi.com
Michael Corrigan
|> It is precisely _because_ I test compilers for a living (and BECAUSE I know
|> at least as well as anyone here how buggy most of THEM are) that all of
|> this ranting and raving about one tiny little firmware glitch seems like
|> a lot of worrying about the arrangement of the deck chairs on the Titanic.
|>
|>
I really hesitate to get involved in this but I thought I'd point out one
difference between this FDIV bug and most compiler errors.
When faced with a compiler that is buggy (as I agree they all are) one must
certainly test the produced code to see that it generates correct results.
Most compiler errors that I've dealt with (and I've dealt with quite a
number) are cases of wrong code generated for a particular path in the
program. Everytime you go down that path you get a bad result.
The difference with the FDIV bug (and a small subset of compiler errors,
usually in the runtime routines) is that it is data dependent.
You can test the generated code until you are blue in the face and it
gives correct answers all the time. Then in production, you get the
unfortunate data pattern and bang! That is why this bug is more serious
than the typical compiler bug.
--
Mike Corrigan
corr...@vnet.ibm.com
bill davidsen
Dan Gezelter <geze...@neon.cchem.berkeley.edu> wrote:
| Yeah. Like quantum scattering code, or fluid dynamics code, or really
| long trajectories for protein chains. ANYONE who inverts large
| matrices for a living is going to get burned by this bug eventually.
| This makes the Pentium completely unacceptable for many scientific and
| engineering applications.
Those applications are pretty esoteric, how about spreadsheets which
work in D.P. internally? Think there would be any repercussions from
getting wrong answers out of your business model?
bill davidsen
Ronald F. Guilmette <r...@rahul.net> wrote:
| Oh come on now. Very serious? As another poster noted, you would have
| to have some mighty specialized code even to be able to NOTICE the problem.
|
| I am a firm beliver in giving vendors (both hardware and software) a really
| hard time when they mess up, but is this particularly obscure floating
| point nit really something that we should be brow beating Intel about?
I am trying hard to be polite in my reply to this, but this is total
hogwash! A CPU which gives incorrect results for operations with certain
initial values is about as useful as a car with brakes which fail at
certain intersections.
Just when I was kicking myself for buying a DX2-80...
bill davidsen
Rana Mansour <usg...@gsusgi2.Gsu.EDU> wrote:
| If I understand all this correctly - at some point Intel learned
| of the problem, fixed it by midsummer, but continued to all allow
| the distribution of chips that were known to be faulty. I think
| that's something we should brow beat Intel about.
And didn't mark the corrected chips in some way that the end user could
identify. I wonder if some user who gets a wrong answer out of a
spreadsheet and loses a lot of money will sue Intel? Most F.P. done in C
is done in D.P. and would be subject to this bug, I would think.
While people are posting programs, how about a macro for Excall or
something?
Paul Gifford
|>>
|>>Note that most of the "the world has come to an end because
|>>there exist P5 chips which produce inaccurate results for
|>>certain operations" posts have come from .edu sites?
|>
|>Yes. I _did_ notice that!
|>
|>Academics! Can't live with 'em. Can't kill 'em.
|>
|>hummmph.
Want some cheese with that whine? Maybe it's because some of us (like me) use Pentiums to do lots of double precision number crunching in our research. If I have to worry that an odd result is due to processor error (as opposed to an error in the code, or something funny in the physics) then I'll never finish my work!
paul
Ed Callahan
>Oh come on now. Very serious? As another poster noted, you would have
>to have some mighty specialized code even to be able to NOTICE the problem.
I it precisely because the bug is not blatant enough to be noticed immediately
that it is so insidious. And plenty of people count on double precision. The
scary part is not all of them read comp.sys.intel.
Ed Callahan
call...@stat.missouri.edu
Luc Bauwens
>
>I would urge you to use more specific language when discussing this.
>I, for one, would not consider the results "incorrect," because they
>are accurate, but with lower precision. To me, correctness = accurate.
>Precision is how finely divided your measurement is.
>_______________________________________________________________________________
> Andy Gough | Internet: andrew_...@ccm.ch.intel.com
> Intel Corporation CH5-131 | ICBM : 111^55'42" W; 33^18'23" N
> 5000 W. Chandler Blvd. | "Knowledge is power."
> Chandler, AZ 85226 | -- Francis Bacon
>-------------------------------------------------------------------------------
>
Hm... Nice try. But shouldn't Intel know better? Or don't they really
have a clue?
Even small, but not expected, inaccuracies in some localized operations
will in many classes of problems lead to results that are completely
wrong, hence *quite* incorrect.
Which is the scary part of this problem.
(And BTW, I can't believe that at this point in the game, any Intel
employee would be allowed tp post anything from an Intel site
without some kind of an endorsement from their damage control folks,
disclaimers notwithstanding. Just as I can't believe it's by accident
that they were completely silent on this forum for almost a week.
It's not by accident that they are now finally coming out of the closet,
is it?)
And when is the official Intel position, if any, finally going to
be publically announced? Or do they plan to duck the issue altogether?
Paul Rubin
------Simon------ <kar...@frodo.ncssm.edu> wrote:
>Also, the FDIV bug is real. I was getting some rather wierd results with
>fdiv errors of 1e-6 or larger using EMACS calc (an add-on for GNU EMACS,
>an RPN calculator that runs in an emacs and is basically a hp-48). I
>then heard of the problem and got a copy of p87test. My pentium 90 does
>have the FDIV bug.
The Emacs calculator is an amazing and great program, and the P5
does have this nasty bug, but the bug is not related to the problem
you describe. The Emacs calculator uses integer arithmetic
exclusively to simulate floating point and exact rational arithmetic
at arbitrary precision. So it is not affected by the FDIV bug.
Try setting the precision higher.
Cave Newt
>I don't know how many cycles a Pentium FDIV takes, but say it is
>100 cycles (hopefully it is really a lot less). Then 9 billion
>FDIV's takes 900 billion cycles. At 90 MHz, that is 10000 seconds
>per FDIV error, or about 3 hours, not 27 years. I wonder where
>they got that 27 year figure from. Maybe they did the calculation
>on a Pentium :-)
27 years == 900 million seconds, at least approximately. Apparently
Intel is assuming ten FDIVs per second...
Greg Roelofs
Andreas Kaiser
> I don't know how many cycles a Pentium FDIV takes, but say it is
> 100 cycles (hopefully it is really a lot less). Then 9 billion
> FDIV's takes 900 billion cycles. At 90 MHz, that is 10000 seconds
> per FDIV error, or about 3 hours, not 27 years.
I've got approximately 2 errors per hour on a P90, using random
numbers. And in the meantime, I received an optimized version.
--------------------
-- Andreas Kaiser -- internet: a...@ananke.s.bawue.de
-------------------- fidonet: 2:246/8506.9
William Schneller
if you use computers intended for the mass market no one is going to care
if you have a problem in some specialized market. Lets just say that
everyone that knows of the existance of comp.sys.intel stops buying intel
processors. What did intel loose a tenth, a hundreth of a percent of a
their market. I keep seeing people post here as if their options had some
meaning. Well I've tried to point out a few times already that this just
is not the case. You are a few hundred people who buy a few thousand
computers. Intel sell tens of millions per year and most of these are
sold to home and business users who would not know and could not care
about FDIV. Yes you could make some arguments that in some rare case
excel might give an error but I don't see it being noticed. So you can
show the bug in MATLAB and probably Maple to. But how many copies of
these packages are out in the market. A couple tens of thousands i.e. a
tenth of a percent of intel's market. Big deal. When are you going to
learn to stop putting so much importance on yourself. If you don't like
Pentium chips don't buy one. If you have a problem the is so important
why are you using a PC. Has is occured to you that if your problem was
really important you would have the money to buy a real computer. Before
you get uppity I happen to use a PC with Linux because noone but me thinks
my problems are all that important. I am trying to convince people
otherwise but until I do I am going have enough sense to realize what I am
using and not expect a multi Billion dollar compony to kiss my but when I
have a problem. Yes intel may loose my bussiness but I don't think they
will loose sleep over it.
Please get a little perspective.
Bill
Trangdaithi Hoang
Royden Yates <r...@beattie.uct.ac.za> wrote:
>Have I missed something or a post indicating to the contrary? It seems to
>me that the som...@x.intel..... folk have been conspicuous by their absence.
>Hell, some weeks ago one could'nt whisper a negative word without some
>rejoinder from "not an official spokeperson for Intel". Where are you chaps?
>Or is the FDIV bug not something about which you are allowed to hold
>'unofficial' opinion?
This is normal operating procedure. When a problem is discovered by the
public, keep quite and don't participate in the discussion as to not fan
the flame. The few knowledgeable ones who are aware of the problem will
grow tired of discussing the problem among themselves and the flame will
eventually burn itself out.
On the other hand, it's your duty as an employee of a company to point
out problems in another company's product and quickly spread the bad
news around the world as many times as you can and as fast as humanly
possible.
Now is the worst time for your closest rival to come out with a
competing product that costs less, is faster at the same clock speed,
and produces not only faster, but more accurate floating point
calculations. Meanwhile, you gamble with your decisions to bear the
cost of replacing the defective products and keep the public's trust
or downplay the situation and risk losing them to your rival.
Jon Jenkins
: Tom Kraljevic (to...@marley.crhc.uiuc.edu) wrote:
: : jenk...@oils.ozy.dec.com (Jon Jenkins) writes:
: : >Or Microwave circuit simulations which is what I bought the thing for ;-)
: : >I was wondering why some of the benchmarks, although faster, gave differring
: : >results in some circumstances. Intel will be getting a phone call on Monday
: : >morning!!
: : If you use any transcendentals at all, the p5 is likely to give
: : different answers than previous generations. This is should not
: : come as a surprise. Answers on any one particular instruction
: : (sin, for instance) shouldn't be off by more than an ULP or two
: : though.
: Yep I do and one other reason was the better transcendentals
: of the Pentium. However, some of the differences are quite
: marked. Some testing has revealed differences ranging from
: FLT_MIN<differences<.1% compared to a 486DX266. Absolute
: errors are hard to define in this system as there are many
: transcendental calculations. But some plots appear to
: have spikes where none did/should exist. Without using
: an arbitrary precision calculator and reproducing a
: system near convergence by hand it wil be difficult
: to assess these.
: The absolute magnitude of the errors encountered
: will vary dramatically from application to application
: and from instance to instance.
: The point I think is that there
: is a known problem and for those doing repetetive
: extended maths in systems where convergence is
: a regualr feature will, at least in some cases, not
: get the "correct" answer, where "correct" is
: intended to imply within the expected potential of
: the hw and sw. How significant these effects will
: be I am not in a position to comment on at this
: stage.
Am now!!
I have only tested this in one instance, a circuit which previously showed
no spikes at around 1.73GHz on either 486DX266 or SunSPARC showed a spike
on the Pentium. Incredibly tedious and unbelievably frustrating repetition
of the matrix inversion on an arbitrary precision calculator has shown
that the 7% diffference is almost totally due to a divide error at a very
early stage in the calculation.
----------------------------------------------------------------------
Name: Dr Jon Jenkins
Location: Digital Equipment Corp, NaC,
Burnett Place, Research Park,
Bond University, Gold Coast
QLD, AUSTRALIA 4229
Phone: 61-75-75-0151
Fax: 61-75-75-0100
Internet: jenk...@ozy.dec.com
The opinions expressed above are entirely personal and do not
reflect the corporate policy of DEC or the opinions of DEC management.
-----------------------------------------------------------------------
Dan Pop
>pl...@cs.swarthmore.edu (Steve Platt) writes:
>
>[ Compiler artifacts, including optimization and type assumptions, hid
>FDIV bug in short C program test ]
>
>Another data point: Once I forced the constants to be double
>precision, the program showed the bug fine. (gcc under linux was used
>to compile.)
You seem to be very confused about floating point constants. An unsuffixed
floating point constant is a double constant.
>
>#define C 824633702449.0L
^^^^^^^^^^^^^^^
This is a long double constant. The original one was double.
Dan
--
Dan Pop
CERN, CN Division
Email: dan...@cernapo.cern.ch
Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
------Simon------
Newsgroups: comp.sys.intel
Path: ecsgate!concert!gatech!swrinde!pipex!uunet!psinntp!fasttech!zeke
From: ze...@fasttech.com (Bohdan Tashchuk)
Organization: Fast Technology --- Beaverton, OR
References: <39rd03$r...@knot.queensu.ca> <Cz0xn...@world.std.com> <39uv8e$s...@hustle.rahul.net> <3a0b2r$j...@agate.berkeley.edu> <3aavqe$7...@usenety1.news.prodigy.com>
Date: Sat, 19 Nov 1994 07:23:42 GMT
Lines: 25
In <3aavqe$7...@usenety1.news.prodigy.com> davi...@tmr.com (bill davidsen) writes:
> >Those applications are pretty esoteric, how about spreadsheets which
> >work in D.P. internally? Think there would be any repercussions from
> >getting wrong answers out of your business model?
> Shhhh. Don't spread this information around. Many people might realize that
> this bug is by no means esoteric, but rather has the potential to affect
> a lot of ordinary business users.
> Intel really is between a rock and a hard place. If they stonewall and try to
> maintain that only a few people are potentially affected, a vocal minority
> will hound them mercilessly. If this minority gets the ear of the press,
> then things could turn ugly, PR-wise. The PowerPC boys could have a field
> day with the advertising. What if they contrived a simple little ten cell
> spreadsheet, showing a PowerPC getting the right answer and a Pentium
> screwing up?
> If Intel fesses up, they could wind up replacing upwards of a million chips.
> The $100 million cost of that would really be chump change to Intel. Still,
> Andy seems like a real tightwad. I'm sure he wouldn't be too anxious to part
> with that kind of money.
--
> Bohdan The Failed Clinton Presidency - America Held Hostage - Day 668
Also, the FDIV bug is real. I was getting some rather wierd results with
fdiv errors of 1e-6 or larger using EMACS calc (an add-on for GNU EMACS,
an RPN calculator that runs in an emacs and is basically a hp-48). I
then heard of the problem and got a copy of p87test. My pentium 90 does
have the FDIV bug. I spoke with Micron (where I got the PC) and they
said that they were waiting to hear from Intel. I got the PC to do
mostly scientific and mathematical work. A pentium under Linux seemed
to be a pretty good deal compared to a risc workstation ($). I propose
that we give Intel ONE WEEK FROM TODAY then flood all computer magazines
with letters to the editor about this problem. Also, we can't forget
Newsweek, with their new computer coverage. Perhaps that will get their
attention and get something done about this problem.
Simon
--
*******************************************************************************
* Simon Karpen kar...@ncssm-server.ncssm.edu *
* flames to /dev/null Linux: choice of the GNU generation *
* #include <disclaimer.h> I don't speak for NCSSM *
*******************************************************************************
Ronald F. Guilmette
bill davidsen <davi...@prodigy.com> wrote:
>In article <pkimCzA...@netcom.com>, Peter Kim <pk...@netcom.com> wrote:
>| In article <3a5oeq$o...@hustle.rahul.net>,
>| Ronald F. Guilmette <r...@rahul.net> wrote:
>
>| >>when those variables are real*4. This bug means that, at some critical
>| >>point in one of my programs, such as when doing a pivot step in a matrix
>| >>inversion, a result that should be accurate to 15 digits may only be
>| >>accurate to 8 or so...
>| >
>| >Wait a minute. Let me get out the violin. You're breaking my heart.
>| >
>| >-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
>| >---- E-mail: r...@segfault.us.com ----------- Purveyors of Compiler Test ----
>| >-------------------------------------------- Suites and Bullet-Proof Shoes -
>
>If this person has the same "it won't effect many people" attitude about
>testing compiler that he has about CPUs, I certainly will let someone
>else "purvey" my test suites.
It is precisely _because_ I test compilers for a living (and BECAUSE I know
at least as well as anyone here how buggy most of THEM are) that all of
this ranting and raving about one tiny little firmware glitch seems like
a lot of worrying about the arrangement of the deck chairs on the Titanic.
If all of you folks out there who are crying up and down about this one
small firmware bug had even a remote idea how many bugs most of your
COMPILERS have in them (many of which are far more serious than this)
you would quickly forget all about Intel and start panicking about your
compiler vendors instead.
But NOOOOOOOOOO! For some reason people seem to want to turn a blind eye
to all of the bugs in all of the compilers out there. People rationalize
this and say `Well, heck. Compilers are software, and we already KNOW that
all software has bugs, and we can't do anything about it so we'll just
pretend all those compiler bugs don't exist. Besides, it's more fun to
verbally abuse a multi-billion dollar chip vendor than it is to beat up
on little old ABC Compiler Company (or, for that matter on that multi-billion
dollar Software Juggernaught that shall remain nameless).
(I've even had compiler _vendors_ say to me... after I had pitched them...
`Yea. So if we buy your compiler test suites, we'll find some more bugs
in our compilers. We know that. So what? That isn't worth a few grand
to us because our customers don't seem to care.')
Obviously, the fact that end users seem all too ready to scream bloody murder
when they hear of one teeny little chip bug while they don't do SQUAT to
hold their COMPILER VENDORS accountable annoys me no end. But what can
I do about it without seeming like just another crass commercial schmuck
making unwarranted/unwelcome use of the Internet to promote my own compiler
test suite products? Answer: Nothing. And besides, the writing is already
on the wall. End users don't seem to give a rats ass that the compilers
they are using are (with some notable exceptions) buggy as hell.
So I can (and will, now that the occasion has presented itself) stand up
here and tell you as loudly and clearly as I can that all of you folks who
are going on and on, and pissing in your pants about the Pentium FDIV bug
are being nothing less than outrageously silly, because you are only looking
at (and worrying about) the tiny tip of a very very large iceberg.
I have a simple suggestion for you all. Why don't you all take just 10%
of the energy that you are now devoting to beating Intel about the head
and neck over this one small slip up and devote it instead to finding out
how well your respective compiler vendors are doing _their_ QA (relative
to Intel and _its_ QA)? Ask them how much they have spent on test suites
relative to their compiler sales.
Who knows, you might just learn something. (But be prepared to be appalled.)
>Anyone who is willing to accept a CPU (or compiler) which just plain doesn't
>work from time to time should be doing something other than QA!
I, for one, am not willing to accept _any_ defects in the computing tools
I use. How about you? What have _you_ done lately to demand more (in the
way of quality) from your suppliers other than bitch and moan about one lone
little firmware bug?
P.S. For awhile there, I was giving out FREE sample test cases from my C
compiler test suite. I announced this in the comp.std.c and comp.lang.c
newgroups. Wanna know how many people lifted a finger to even *try* to
put their compilers through some simple tests? A few dozen. That's it.
I really _would_ like to know what it is about human psychology that causes
people to get totally up in arms about a small firmware glitch (like this
FDIV thing) while they merely yawn at the prospect of DOZENS of serious
bugs in their compilers.
If any of you out there are psychology majors, and if you can explain this
to me, please do. I must confess, it's an enigma to me.
P.P.S. If there is anyone who is reading this who cares about the TOTAL
quality of your computing system, please send mail to the address below.
If there is sufficient interest, I'll put my free sample compiler test
cases up for anonymous FTP again.
--
William Schneller
>In article <3annh5$u...@emerald.tufts.edu>,
>William Schneller <wsch...@emerald.tufts.edu> wrote:
>>if you have a problem in some specialized market. Lets just say that
>>everyone that knows of the existance of comp.sys.intel stops buying intel
>>processors. What did intel loose a tenth, a hundreth of a percent of a
>>their market. I keep seeing people post here as if their options had some
>>meaning. Well I've tried to point out a few times already that this just
>>is not the case. You are a few hundred people who buy a few thousand
>>computers.
>
>and if I own a Pentium and that my calculations were affected
>by the FDIV bug, I sure as hell would complain about it, what other
>people do with their Pentium pc is irrelevant to me, what *is* relevant
>is that my work has been affected by the FDIV bug. Using the same
>argument, let's a monitor manufacturer made a CRT that fails randomly
>at 1280x1024 resolution, let's say I happens to use that resolution.
>Should I say to myself, "well most people run at 1024x768 resolution,
>that makes me unimportant, I probably should not complain about the
>monitor." Do you realize how stupid that sounds?
I realize exactly how it sounds and yes if 99.9% of the buyers of
that monitor use the 1024 you are not important and your problem
has no meaning. Why? It would cheaper for them to loose your
bussiness than fix the problem. Yes it's too bad and sad that
this is the way the world works but you really don't matter. If
your are going to get mad when you go out of the bounds of the
most common behavior and things fail, either don't go or take extra
precuasions. But don't piss and whine. There are reasons things
cost what they do. Sometimes someone is price guaging but more
often you are getting what you pay for. Yes intel made a big
mistake. But in reallity, does it really affect the vast majority
of their customers? No. The point is you are complaining to bussiness
that is out to make money and solving your problem is probably not
financially expidient. Sorry life is not fair.
>
>[stuff deleted]
>>tenth of a percent of intel's market. Big deal. When are you going to
>>learn to stop putting so much importance on yourself. If you don't like
>>Pentium chips don't buy one. If you have a problem the is so important
>>why are you using a PC.
>
> People complain because they've already bought the Pentium chip,
>and to say using a PC to only solve problems that are "unimportant" is
>just plain stupid. You use whatever resources you have to solve a
>problem, and a Pentium PC has the best bang for the bucks vs other
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Well appearently there is a reason that bang came so cheap. If intel
wants to convince the science and engineering worlds that PCs are not
the "toys" that people think of them as they should be more careful
about problems like this. They seem to not really care too much. Why?
This problem has little to do with their real market. So maybe you should
use a work station.
Why can't people understand just how small the sciences are in the market
scemes of the PC world? We are a few percentages. Nothing, no one, nobody.
Please drop this "Oh, Intel didn't return my call" stuff. If they don't
call buy something else and be done with it.
>solutions then so be it. You really should go out to the real world
>sometime, you'll be amazed how much "real" work is done on PC.
I am amazed at what people call "real" work. So, I doubt I would amazed
at how much "real" work is done on PCs.
I was told that their is no center of the universe but when I talk to
people I get the impression there are millions of centers of the
universe all crashing into each other.
>
>>Please get a little perspective.
>>Bill
>
> Same to you.
>
>+=---------------------------------Linux/Star Trek TNG fanatic---=+
> Stephen Lau, Grad. School, Elec. Engineering, Stanford University
> InterNet: cl...@leland.stanford.edu, cl...@netcom.com
> "This is getting on my nerves, now that I have them." - Q
James T. McKinley
>Newsgroups: comp.sys.intel
>Path:
>msuinfo!uwm.edu!cs.utexas.edu!howland.reston.ans.net!gatech!concert!ecsgate!unce
>cs.edu!karpens
>From: kar...@frodo.ncssm.edu (------Simon------)
>Subject: Re: FDIV bug in Pentium chips!
>In-Reply-To: ze...@fasttech.com's message of Sat, 19 Nov 1994 07:23:42 GMT
>Message-ID: <KARPENS.94...@frodo.ncssm.edu>
>Sender: use...@ecsvax.uncecs.edu (News Administrator)
>Organization: North Carolina School of Science and Math
>References: <39rd03$r...@knot.queensu.ca> <Cz0xn...@world.std.com>
> <39uv8e$s...@hustle.rahul.net> <3a0b2r$j...@agate.berkeley.edu>
>Date: Sat, 19 Nov 1994 23:11:45 GMT
>Lines: 55
I agree whole-heartedly, I am a physics grad. student who also
bought my P5 to do scientific calcs. (some non-linear simulations)
as well as other things (i.e. 3d graphics & visualization). I say if Intel
doesn't offer to replace the affected CPU's for those who ask we hit 'em where
it hurts, namely their profits. I think some friendly phone calls
to Intel's competitors in time for TV ads to be produced for the
holiday season might do the trick, if they don't already know.
The problem with the PC rags is that they are usually 3 months
behind (calls or letters now might not show up as a story until Jan.
or Feb. for PC Magazine). Of course spreading the word more
widely on the net might help as well. Time is of the essence here,
this is the largest retail season of the year. I am surprised I
haven't seen anything about this in the mass media yet.
Jim
Jon Jenkins
lots and lost deleted
: Am now!!
: I have only tested this in one instance, a circuit which previously showed
: no spikes at around 1.73GHz on either 486DX266 or SunSPARC showed a spike
: on the Pentium. Incredibly tedious and unbelievably frustrating repetition
: of the matrix inversion on an arbitrary precision calculator has shown
: that the 7% diffference is almost totally due to a divide error at a very
: early stage in the calculation.
Am not !!
I has been pointed out to me that the floating point control
register is initialised to a different value in the 486 than
in the 586. A few other compiler possibilities and "gotchas"
have also been sent by email. Until I sort these out and eliminate
them as possibile causes of the above "error" I will have to retract
said statement. Suffice to say that many others are also finding
the "bug" so I presume that although there is a high probability that it
is the cause of the differnce it is possible that an incorrect setting
of a x87 control register that is causing the difference.
Does anyone know if Borland C++4.0 initialises the fp cvontrol
register correctly under NT (or does NT do it ??)
Ditto for gcc under BSD ??
cmo...@sedona.intel.com
Luc Bauwens <bau...@acs.ucalgary.ca> wrote:
>
>(And BTW, I can't believe that at this point in the game, any Intel
>employee would be allowed tp post anything from an Intel site
>without some kind of an endorsement from their damage control folks,
>disclaimers notwithstanding. Just as I can't believe it's by accident
>that they were completely silent on this forum for almost a week.
>It's not by accident that they are now finally coming out of the closet,
>is it?)
Hi Luc, We haven't been in the closet. Most of the Intel folk who post
here are from Chandler, AZ and support products like MCS-51, MCS-96,
i960... all unofficially. We are a long way from Santa Clara and not
involved with Pentiums.
Since there are no official Intel spokespersons on this newsgroup, looking
for an official Intel response here is like looking for your keys under
the streetlight where the light is good instead of where you lost them.
--
---------------------------------------------------------------
Intel has shipped over 100,000,000 MCS-96 Microcontrollers
---------------------------------------------------------------
Cecil_...@ccm.ch.intel.com MCS-96 Architectural Engineer
Intel Corp., CH3-46, 5000 W. Chandler Blvd., Chandler, AZ 85226
Opinions expressed on Internet are my own personal fuzzy logic.
I am not an official spokesman for Intel Corp.
Terje Mathisen
>[snip]
>Am not !!
>I has been pointed out to me that the floating point control
>register is initialised to a different value in the 486 than
>in the 586. A few other compiler possibilities and "gotchas"
>have also been sent by email. Until I sort these out and eliminate
>them as possibile causes of the above "error" I will have to retract
>said statement. Suffice to say that many others are also finding
>the "bug" so I presume that although there is a high probability that it
>is the cause of the differnce it is possible that an incorrect setting
>of a x87 control register that is causing the difference.
This (different PC default) is most definitely _not_ the problem!
The reason is really very simple:
1) The first F(N)INIT performed after reset will force the PC bits to the
normal 80-bit (extended precision) setting.
2) The canonical way for a x87 library to test for the presence of the ndp
starts with FNINIT, followed by FNSTSW [StatusWord]. The [StatusWord]
variable have been set to a know value (zero) before the FNSTSW
instruction.
If [StatusWord] contains a specific bit pattern after these two fp opcodes,
an NDP must be present.
I believe every single compiler fp library will use this sequence, which
will reset the PC bits to their normal value.
My p87test program uses the very same code to check for ndp availability
before testing the FDIV results.
The only cloud on the horizon, is that Intel have included a bit in the
CPUID feature list, which specifies ndp availability. If fp lib vendors
started to use this bit instead of the FNINIT/FNSTSW test, and then skipped
the needed FINIT before program startup, we might find ourselves in
single-precision mode.
(Why Intel would change the default PC boggles my mind!)
-Terje Mathisen (include std disclaimer) <Terje.M...@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
John Hesse
>
>As I said in a separate posting, please put up or shut up.
>
>Please name one person who has been materially affected by this exceedingly
>rare bug.
>
O. J. Simpson, you ninny. Don't you ever read the news?
--
- - - - - - - - - - - - - - -
John Hesse
Moss Beach, Calif
jhe...@netcom.com
- - - - - - - - - - - - - - -
Larry Hoyle
What if the ABS system keeps track of braking force and stops your car
in front of the train instead of before the track because most of the
time the calculations are double precision but just that once they are
not.
Andrew M. Gough (andrew_...@ccm.ch.intel.com) wrote:
: In article <3aavg5$9...@usenety1.news.prodigy.com>, bill davidsen writes:
: > In article <39uv8e$s...@hustle.rahul.net>,
: > Ronald F. Guilmette <r...@rahul.net> wrote:
: >
: > | Oh come on now. Very serious? As another poster noted, you would have
: > | to have some mighty specialized code even to be able to NOTICE the problem.
: > |
: > | I am a firm beliver in giving vendors (both hardware and software) a really
: > | hard time when they mess up, but is this particularly obscure floating
: > | point nit really something that we should be brow beating Intel about?
: >
: > I am trying hard to be polite in my reply to this, but this is total
: > hogwash! A CPU which gives incorrect results for operations with certain
: > initial values is about as useful as a car with brakes which fail at
: > certain intersections.
: I would urge you to use more specific language when discussing this.
: I, for one, would not consider the results "incorrect," because they
: are accurate, but with lower precision. To me, correctness = accurate.
: Precision is how finely divided your measurement is.
: So your analogy is not analogous. A better one would be "as useful
: as a car with brakes which change the stopping distance by one
: picometer at certain intersections."
: >
: > Just when I was kicking myself for buying a DX2-80...
: Resume kicking. ;-)
: Regards,
: Andy
: Disclaimer:
: All views expressed are my own opinions, and not necessarily
: those of Intel Corporation.
: _______________________________________________________________________________
Steve Masticola
>>Another data point: Once I forced the constants to be double
>>precision, the program showed the bug fine. (gcc under linux was used
>>to compile.)
>You seem to be very confused about floating point constants. An unsuffixed
>floating point constant is a double constant.
You seem to be very pedantic about C nomenclature. An unsuffixed
floating point constant fails to show the bug.
>>#define C 824633702449.0L
>This is a long double constant. The original one was double.
This is a constant that shows the bug on the system described. The
original one hid it.
Do you actually have something technical to contribute other than a
smarmy grammar lecture?
- Steve (mast...@scr.siemens.com).
ke...@infoserv.com
edge of CPU technology. With millions of transitors you
are bound to get a screw case bug. This is it for the
Pentium. Other CPUs have had problems also.
I figure if you can wait for a CPU to mature for about
12 months of volume shipping you will get a product
that has the first bugs fixed.
Kent
--
/* "There is no king who has not had a slave among his ancestors and */
/* no slave that has not had a king among his." ---- Helen Keller */
/* Kent L. Shephard ----- K. L. Shephard Consulting */
Chung Lau
>everyone that knows of the existance of comp.sys.intel stops buying intel
>processors. What did intel loose a tenth, a hundreth of a percent of a
>their market. I keep seeing people post here as if their options had some
>meaning. Well I've tried to point out a few times already that this just
>is not the case. You are a few hundred people who buy a few thousand
>computers.
What kind of stupid argument is that? I use MATLAB a lot,
and if I own a Pentium and that my calculations were affected
by the FDIV bug, I sure as hell would complain about it, what other
people do with their Pentium pc is irrelevant to me, what *is* relevant
is that my work has been affected by the FDIV bug. Using the same
argument, let's a monitor manufacturer made a CRT that fails randomly
at 1280x1024 resolution, let's say I happens to use that resolution.
Should I say to myself, "well most people run at 1024x768 resolution,
that makes me unimportant, I probably should not complain about the
monitor." Do you realize how stupid that sounds?
[stuff deleted]
>tenth of a percent of intel's market. Big deal. When are you going to
>learn to stop putting so much importance on yourself. If you don't like
>Pentium chips don't buy one. If you have a problem the is so important
>why are you using a PC.
People complain because they've already bought the Pentium chip,
and to say using a PC to only solve problems that are "unimportant" is
just plain stupid. You use whatever resources you have to solve a
problem, and a Pentium PC has the best bang for the bucks vs other
solutions then so be it. You really should go out to the real world
sometime, you'll be amazed how much "real" work is done on PC.
>Please get a little perspective.
>Bill
Same to you.
Dan Pop
>dan...@cernapo.cern.ch (Dan Pop) writes:
>
>>>Another data point: Once I forced the constants to be double
>>>precision, the program showed the bug fine. (gcc under linux was used
>>>to compile.)
>
>>You seem to be very confused about floating point constants. An unsuffixed
>>floating point constant is a double constant.
>
>You seem to be very pedantic about C nomenclature. An unsuffixed
>floating point constant fails to show the bug.
>
>>>#define C 824633702449.0L
>
>>This is a long double constant. The original one was double.
>
>This is a constant that shows the bug on the system described. The
>original one hid it.
>
another program, posted by Thomas Koenig, that shows the bug using only
unsuffixed floating constants and gcc under Linux:
#include <stdio.h>
int main()
{
double x,y,z;
x = 4195835.0;
y = 3145727.0;
z = x - (x / y) * y;
printf("%f\n",z);
return 0;
}
>Do you actually have something technical to contribute other than a
>smarmy grammar lecture?
>
It was a basic C lecture for someone who seemed to be completely clueless
about that topic. Sorry for disturbing your cluelessness.
P.S. Only idiots redirect follow-ups to alt.test, hoping that the responder
is even more stupid than them and won't notice the cheap trick.
Javier Vizcaino
: suggestion that Intel would ask me for proof of what I'm using the chip for
: before offering to replace it. That isn't their business. I paid out my
: hard earned dollars for a chip and I want it to operate 100% or I want my
: money back. Period.
: --
: Thomas A. Gauldin Here's to the land of the longleaf pine,
: Raleigh, NC The summerland where the sun doth shine,
: BSRB45A on Prodigy Where the weak grow strong and the strong grow great,
: FAX (919) 676-1404 Here's to Downhome, the Old North State.
Well, this was what the egg frying Pentium needed. I would like to make a few
considerations:
-I remember an old announcement of calculators, normally priced around $100
(probably $99.95) which were sold around $50 (probably $49.95). It was CLEARLY
said that the calculators displayed cos(0)=0.
-I have seen that for x=4195835.0 and y=3145727.0 x-(x/y)*y gives 256.0 on a
buggy Pentium. Is this so? What if someone writes a program with "if
(something like above) > say 255.9 then fire the missile..."?
-A lot of time ago I purchased a TI59 hand held calculator. The first one I
tried had too many failures, which I saw in one day. It was exchanged without
questions. Some time later, I saw it exhibited bit pattern sensitivity; TI
changed the electronics again without questions.
-I have tried the operation above on the TI59 and I get 0.000001, as you see
a bit less than 256.
-I have tried the operation above on an "antique computer" XT clone with 8087
(making sure I had FDIV's in the code) and I get 0.0 with 20 decimal figures.
What is a Pentium for?
-I would certainly buy now a 486, not a Pentium. At least, I would do the
check.
-As for software bugs, in essence software makers market their failures. If a
new version is sold, it should include new features only, but it perhaps
corrects old bugs, and surely introduces new bugs. People are so concerned
with versions 1.0 that some software makers start their marketed version
labelling it 6.0.
-I think makers of checker software should include a check for buggy Pentium's
and scientific software programs should check and perhaps say "I may give
incorrect results. Continue? (y/n) [n]"
-PC makers with Pentium clones inside may announce them "Intel Pentium not
inside".
-Be aware with your bank accounts. Banks will look for buggy Pentiums, will
place them in well chosen places, will do calculations in a certain way, and
cent by cent, they will swallow all your money. What about reversing the
thing, putting certain amounts of money in and out, and in this way become a
millionaire?
Javier Vizcaino. jviz...@colibri.tid.es
The points of view above are mine, not my employer's.
Marc A. Murison
>In article <16NOV199...@ariel.lerc.nasa.gov>,
>Duane Mattern (NYMA) <mat...@ariel.lerc.nasa.gov> wrote:
>>I called and talked to Helen. SHE stated that Intel does not know
>>who at Intel did the interview and that Intel has no plans to replace
>>microprocessor. She stated that the problem is way over blown and
>>that Intel claims that users would only see an error once every 27 years
>>or an error rate of 1 in 9 billion. I told Helen that Intel better
>>make an announcement on the InterNet soon or they'd have big publicity
>>problem on their hands.
>I don't know how many cycles a Pentium FDIV takes, but say it is
>100 cycles (hopefully it is really a lot less). Then 9 billion
>FDIV's takes 900 billion cycles. At 90 MHz, that is 10000 seconds
>per FDIV error, or about 3 hours, not 27 years. I wonder where
>they got that 27 year figure from. Maybe they did the calculation
>on a Pentium :-)
A real-life example: I wrote a loop that does nothing but test y*(1.0/y), and
on my (flawed, of course) P90 it churned through 100 billion values of y in a
couple of days or so (wasn't really keeping track of time spent). Found >600
numbers. So the 27 yr number is a bald lie, and the canonical "1 out of 10
billion" error rate often spouted from Intel people is also rather
"optimistic". And I'm getting really annoyed at the runarounds I'm getting
from phone calls (at my expense!) to Intel. Jerks.
---------------------------------------------------------------------
| Marc A. Murison | Smithsonian Astrophysical Observatory |
| mur...@cfa.harvard.edu | 60 Garden Street, MS 63 |
| (617) 495-7079 | Cambridge, MA 02138 |
---------------------------------------------------------------------
Marc A. Murison
>as a car with brakes which change the stopping distance by one
>picometer at certain intersections."
BZZZT! Wrong. Some of us blow weeks at a time on a single calculation. If
at any time during these kinds of calculation a single precision blip occurs,
the whole calculation is trashed. And, given the error rate is roughly 1 in
200 million or so, we're guaranteed to get blipped many times per week. This
makes the Pentium useless for some of us.
Craig Milo Rogers
>I would urge you to use more specific language when discussing this.
>I, for one, would not consider the results "incorrect," because they
>are accurate, but with lower precision. To me, correctness = accurate.
>Precision is how finely divided your measurement is.
Implementations of IEEE math are supposed to produce results
within a certain LSB range, for a given datatype. The Intel Pentium
implementation fails to do so. The results are clearly incorrect.
In other words, to be correct, you must be both accurate and precise.
Craig Milo Rogers
------Simon------
Path: ecsgate!concert!rutgers!sgigate.sgi.com!olivea!spool.mu.edu!howland.reston.ans.net!swiss.ans.net!jabba.cybernetics.net!cybernetics.net!scoundrl
From: scou...@cybernetics.net (Thomas Gauldin)
Newsgroups: comp.sys.intel
Date: 20 Nov 1994 22:30:09 GMT
Organization: Creative Cybernetics, Inc.
Lines: 41
References: <785286...@ananke.s.bawue.de> <3annh5$u...@emerald.tufts.edu> <3ao5k6$a...@nntp.Stanford.EDU> <3ao80p$e...@emerald.tufts.edu>
NNTP-Posting-Host: server0.cybernetics.net
In article <3ao80p$e...@emerald.tufts.edu>,
William Schneller <wsch...@emerald.tufts.edu> wrote:
>In article <3ao5k6$a...@nntp.Stanford.EDU> cl...@leland.Stanford.EDU (Chung Lau) writes:
>>In article <3annh5$u...@emerald.tufts.edu>,
>>William Schneller <wsch...@emerald.tufts.edu> wrote:
>>>if you have a problem in some specialized market. Lets just say that
>>>everyone that knows of the existance of comp.sys.intel stops buying intel
>>>processors. What did intel loose a tenth, a hundreth of a percent of a
DELETED
>
>I realize exactly how it sounds and yes if 99.9% of the buyers of
>that monitor use the 1024 you are not important and your problem
>has no meaning. Why? It would cheaper for them to loose your
>bussiness than fix the problem. Yes it's too bad and sad that
>this is the way the world works but you really don't matter. If
>your are going to get mad when you go out of the bounds of the
>most common behavior and things fail, either don't go or take extra
>precuasions. But don't piss and whine. There are reasons things
DELETED
You are ignoring the effect that even this discussion has on Intel. This
very moment, folks are telling each other that "there is a bug in the Intel
P-90 chip that causes incorrect results." The effect is to NOT just lose
the business of individuals who are considering a P-90 for heavy number
crunching. I suspect that we will find that MOST people will soon call it
"the buggy chip." The effect will be very bad for Intel sales. Whether the
chip is 100% for running a Sierra game or Procomm2, is immaterial. Its the
perception of the ill-informed buying public that will cause the harm.
I'm writing this on a Plato MB with P-90 chip and I'm mad as hell at the
suggestion that Intel would ask me for proof of what I'm using the chip for
before offering to replace it. That isn't their business. I paid out my
hard earned dollars for a chip and I want it to operate 100% or I want my
money back. Period.
--
Thomas A. Gauldin Here's to the land of the longleaf pine,
Raleigh, NC The summerland where the sun doth shine,
BSRB45A on Prodigy Where the weak grow strong and the strong grow great,
FAX (919) 676-1404 Here's to Downhome, the Old North State.
I agree. If you paid for the chip, then you should have a 100% working chip.
Also, I have seen the results of the bug running some long calculations
(mostly divisions). Also, I ran a short program (I wrote for testing)
that, with the same drivers and kernel on a 486, computes pi to
ten decimal places in x iterations on a 486 and the answer was WRONG on
my P90. It was only accurate to 5 decimal places. The calculations
all use doubles. They were both tested under kernel 1.1.62 and gcc 2.5.8
and 2.6.2 on linux pcs. Also, I got a C on a lab that I used mathcad
(probably the only reason I keep windoze around) on and got an answer
that was only correct to 3 sig figs and should have been to 5 or better.
A friend with a 486 got the right answer. I want that chip replaced
VERY SOON and if it is not, I will write to every computer magazine and
news magazine that I know of.
Kevin N Gurney
>
> Why can't people understand just how small the sciences are in the market
> scemes of the PC world? We are a few percentages. Nothing, no one, nobody.
^^^^^^^^^^^^^^^^^6
> Please drop this "Oh, Intel didn't return my call" stuff. If they don't
> call buy something else and be done with it.
The people who work in the City (Wall St in US) are a tiny minority.
They are investing billions of dollars/pounds every day - maybe they
use Pentiums to do their calculations? They go on to lose millions of
dollars because of a small rounding error - who cares - They are only a
tiny minority - (but meanwhile peoples pensions and investments get
screwed up)
Other similar but less impressive examples ad nauseum (with "tiny
minority" liberally sprinkled throughout)
Ho hum...
------------------------------------------------------------
Kevin Gurney
Dept. Human Sciences, Brunel University, Uxbridge, Middx., UK
email: Kevin....@brunel.ac.uk
------------------------------------------------------------
Thomas Gauldin
------Simon------ <kar...@frodo.ncssm.edu> wrote:
>In article <3aoilh$b...@jabba.cybernetics.net> scou...@cybernetics.net (Thomas Gauldin) writes:
>
DELETED
>
> I'm writing this on a Plato MB with P-90 chip and I'm mad as hell at the
> suggestion that Intel would ask me for proof of what I'm using the chip for
> before offering to replace it. That isn't their business. I paid out my
> hard earned dollars for a chip and I want it to operate 100% or I want my
> money back. Period.
> --
DELETED
>A friend with a 486 got the right answer. I want that chip replaced
>VERY SOON and if it is not, I will write to every computer magazine and
>news magazine that I know of.
> Simon
DELETED
I am in the process of alerting our local newspaper in Raleigh of the bug
problem. They may not decide to follow up on it, but if they DO, the IBM
crowd here in the Triangle and the universities will surely become aware of
it.
Bill Broadley
I wrote a small program to just do division and check the results.
I get one error every 21 minutes.
--
Bill Broadley Broa...@math.ucdavis.edu UCD Math Sys-Admin
Linux is great. http://ucdmath.ucdavis.edu/~broadley PGP-ok
Henry Spencer
>I realize exactly how it sounds and yes if 99.9% of the buyers of
>that monitor use the 1024 you are not important and your problem
>has no meaning. Why? It would cheaper for them to loose your
Harvard Business School would be proud of you. But don't bother trying
to get a job in Japan.
--
Little minds have only room for thoughts | Henry Spencer
of bread and butter. --Amundsen | he...@zoo.toronto.edu
Sean Harp
>
>>It will make NO difference when you are playing DOOM, doing
>>simulation modelling, using your favorite spreadsheet, etc.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Just tried the famous example z = x - (x/y)*y
> where x = 4195835 and y = 3145727 on good old Microsoft Excel.
> And it bombed!!!
Nothing personal, but...
######
# # ###### # # ##### # # # # # ####
# # # ## # # # # # ## ## #
###### ##### # # # # # # # # ## # ####
# # # # # # # # # # # #
# # # ## # # # # # # # #
# ###### # # # # #### # # ####
#####
# # # # #### # #
# # # # # # #
##### # # # ####
# # # # # #
# # # # # # # #
##### #### #### # #
Sean Harp (using a real processor)
gregor t. overney
Bill Broadley <broa...@turing.ucdavis.edu> wrote:
>
>I wrote a small program to just do division and check the results.
>
>I get one error every 21 minutes.
>
GTO
Thomas Gauldin
William Schneller <wsch...@emerald.tufts.edu> wrote:
>In article <3ao5k6$a...@nntp.Stanford.EDU> cl...@leland.Stanford.EDU (Chung Lau) writes:
>>In article <3annh5$u...@emerald.tufts.edu>,
>>William Schneller <wsch...@emerald.tufts.edu> wrote:
>>>if you have a problem in some specialized market. Lets just say that
>>>everyone that knows of the existance of comp.sys.intel stops buying intel
>>>processors. What did intel loose a tenth, a hundreth of a percent of a
DELETED
>
>I realize exactly how it sounds and yes if 99.9% of the buyers of
>that monitor use the 1024 you are not important and your problem
>has no meaning. Why? It would cheaper for them to loose your
>bussiness than fix the problem. Yes it's too bad and sad that
>this is the way the world works but you really don't matter. If
>your are going to get mad when you go out of the bounds of the
>most common behavior and things fail, either don't go or take extra
>precuasions. But don't piss and whine. There are reasons things
DELETED
You are ignoring the effect that even this discussion has on Intel. This
very moment, folks are telling each other that "there is a bug in the Intel
P-90 chip that causes incorrect results." The effect is to NOT just lose
the business of individuals who are considering a P-90 for heavy number
crunching. I suspect that we will find that MOST people will soon call it
"the buggy chip." The effect will be very bad for Intel sales. Whether the
chip is 100% for running a Sierra game or Procomm2, is immaterial. Its the
perception of the ill-informed buying public that will cause the harm.
I'm writing this on a Plato MB with P-90 chip and I'm mad as hell at the
suggestion that Intel would ask me for proof of what I'm using the chip for
before offering to replace it. That isn't their business. I paid out my
hard earned dollars for a chip and I want it to operate 100% or I want my
money back. Period.
--
Kazimir Kylheku
>In <CzMn1...@scr.siemens.com> mast...@scr.siemens.com (Steve Masticola) writes:
>
>>dan...@cernapo.cern.ch (Dan Pop) writes:
>>
>>>>Another data point: Once I forced the constants to be double
>>>>precision, the program showed the bug fine. (gcc under linux was used
>>>>to compile.)
Here is a totally overblown program that writes out a file of floating
point numbers into a file using Sun XDR, and using a command-line
switch can compare its results to an existing file. The code is quite
portable to many systems, and so is the file that it creates. You need
Unix with SunRPC extensions to compile it. If you use NFS or Yellow
Pages/NIS, you most certainly have SunRPC.
/****************************************************************************
* "pentbug.c" - a program to compare the floating-point division accuracy *
* of a wide variety of machines, inspired by rumours of a pentium FDIV bug *
****************************************************************************/
/*
pentbug takes a single argument, which can be 'g' or 'c'.
The 'g' stands for "generate". In this mode, pentbug will generate
a file containing floating point numbers called "pentbug.num"
The 'c' stands for "compare". Run in this mode, pentbug will read
the file "pentbug.num" and compare to its own calculations.
Discrepancies are sent to standard output, and may therefore be
redirected to a file.
Pentbug requires the Sun XDR (eXternal Data Representation) library
for converting double-precision floats into machine-independent,
canonicla form (which happens to be the IEEE format). Thus all the
XDR caveats about floats apply! On machines whose floating
representation dosn't "fit" nicely into the IEEE paradigm, there
may be errors introduced by packing or unpacking.
*/
#include <math.h>
#include <stdio.h>
#include <string.h>
#include <rpc/rpc.h>
#define VERS "1.0K" /* program version */
#define FNAM "pentbug.num" /* output/comparison file name */
#define COUNT 10000 /* generate 10,000 numbers */
#define NUMER 1.0 /* division numerator */
#define START 0.12345789123 /* starting value */
#define INCR 0.00002234551 /* arbitrary increment */
#define MAXV 20 /* maximum bytes in version */
/* The test embodied in this program is somewhat naive. I encourage
the development of a better one. Just be sure to choose a different
"VERS" so there isn't any confusion!
*/
static char *VR = VERS;
static void error(void)
{
perror("pentbug");
exit(1);
}
int main(int argc, char *argv[])
{
XDR inout;
FILE *numfile;
char *version = NULL;
double testnum, compnum;
int i;
if (argc != 2) {
printf("Usage: pentbug <c|g>\n");
printf("This is pentbug v%s\n",VERS);
exit(1);
}
switch(argv[1][0]) {
case 'g' :
numfile = fopen(FNAM,"wb");
if (!numfile)
error();
version = VERS;
xdrstdio_create(&inout,numfile,XDR_ENCODE); /* create encoding stream */
if (xdr_string(&inout,&VR,MAXV) == FALSE) /* first store version */
error();
for (i = 0; i < COUNT; i++) {
testnum = ((double) i) * INCR + START; /* better than iter. adds */
testnum = NUMER / testnum;
if (xdr_double(&inout,&testnum) == FALSE)
error();
}
fclose(numfile);
break;
case 'c' :
numfile = fopen(FNAM,"rb");
if (!numfile)
error();
xdrstdio_create(&inout,numfile,XDR_DECODE); /* create decoding stream */
if(xdr_string(&inout,&version,MAXV) == FALSE)
error();
if(strcmp(version,VR)) {
fprintf(stderr,"File made by v%s. This is v%s.\n",version,VERS);
exit(1);
}
for (i = 0; i < COUNT; i++) {
testnum = ((double) i) * INCR + START; /* better than iter. adds */
testnum = NUMER / testnum;
if (xdr_double(&inout,&compnum) == FALSE)
error();
if (testnum != compnum)
printf("%-5.5d: file: %.20e prog: %.20e\n",i,compnum,testnum);
}
fclose(numfile);
break;
default:
printf("pentbug: unknown option '%s'\n",argv[1]);
exit(1);
}
}
Have fun, whatever....
Bill Broadley
: >
: Can you submit this program to this newsgroup? Thanks.
It and many other fdiv related programs are available at
math.ucdavis.edu:/pub/fdiv
jfp...@is.nyu.edu
>: I'm writing this on a Plato MB with P-90 chip and I'm mad as hell at the
>: suggestion that Intel would ask me for proof of what I'm using the chip for
>: before offering to replace it. That isn't their business. I paid out my
>: hard earned dollars for a chip and I want it to operate 100% or I want my
>: money back. Period.
>: --
>: Thomas A. Gauldin Here's to the land of the longleaf pine,
>: Raleigh, NC The summerland where the sun doth shine,
>: BSRB45A on Prodigy Where the weak grow strong and the strong grow great,
>: FAX (919) 676-1404 Here's to Downhome, the Old North State.
>
>Well, this was what the egg frying Pentium needed. I would like to make a few
>considerations:
>-I remember an old announcement of calculators, normally priced around $100
>(probably $99.95) which were sold around $50 (probably $49.95). It was CLEARLY
>said that the calculators displayed cos(0)=0.
>-I have seen that for x=4195835.0 and y=3145727.0 x-(x/y)*y gives 256.0 on a
>buggy Pentium. Is this so? What if someone writes a program with "if
$20 Sharp sci. calc. comes up with 0 even. I would think that Intel now has no
ground at all to not replace all chips. I was not concerned about this too much
since I don't do FP intensive stuff, but when simple (or at least relatively
simple) spreadsheet calculations are affected, the useability of the Pentiums
for anything even remotely related to math is questionable. Intel is going to
have to replace all of the chips or risk a class-action suit against them.
==========================================James Prudente
-NYU Stern School Of Business------...@is.nyu.edu
______________________________________________________
"Don't Damn Me When I Speak of Mind, `cause silence isn't golden
when I'm holding it inside..." - Axl Rose
______________________________________________________