Slashdot Mirror
Where Intel Processors Fail At Math (Again)
rastos1 writes: In a recent blog, software developer Bruce Dawson pointed out some issues with the way the FSIN instruction is described in the "Intel® 64 and IA-32 Architectures Software Developer's Manual," noting that the result of FSIN can be very inaccurate in some cases, if compared to the exact mathematical value of the sine function.
Dawson says, "I was shocked when I discovered this. Both the fsin instruction and Intel's documentation are hugely inaccurate, and the inaccurate documentation has led to poor decisions being made. ... Intel has known for years that these instructions are not as accurate as promised. They are now making updates to their documentation. Updating the instruction is not a realistic option."
Intel processors have had a problem with math in the past, too.
Dawson says, "I was shocked when I discovered this. Both the fsin instruction and Intel's documentation are hugely inaccurate, and the inaccurate documentation has led to poor decisions being made. ... Intel has known for years that these instructions are not as accurate as promised. They are now making updates to their documentation. Updating the instruction is not a realistic option."
Intel processors have had a problem with math in the past, too.
The documentation says that the result will be correct until the last decimal place. So if the CPU says the answer is:
0.123 456 789 123 456 789
You have have a close approximation, accurate to the 17th decimal place, according to the documentation.
The problem is, the correct answer may be:
0.123 444 555 666 777 888
The documentation says it's fairly precise. In truth, it's only good to the fourth decimal place in some cases, whereas Intel documented the function to be accurate to 66 bits or so.
The headline is quite inaccurate. The processors are doing what they're designed to do; approximate the results of certain operations to a "good enough" value to achieve an optimal result:work ratio. Sort of like how the NFL measures first-downs with a stick, a chain, and some eyeballs rather than bringing in a research team armed with scanning electron microscopes to tell us how many Planck lengths short of the first down they were.
This is a documentation failure. They're fixing the documentation. For anyone who would actually care about perfect accuracy in these kinds of operations, there are any number of different solutions to achieve the desired, more accurate result. The headline and the summary make it seem as though there's a problem with the processor which is simply incorrect.
-- "Government is the great fiction through which everybody endeavors to live at the expense of everybody else."
The error is not small. If you read the article, on certain very reasonable inputs (not pathological at all), you can sometimes wind up with only _four_ bits being correct.
Many scientific applications absolutely depend on fast hardware sine implementation. As you said, getting it exactly right isn't a tradeoff that people usually want to make.
This has nothing to do with the C standard. Intel's own documentation was incorrect, making 'YMMV' completely moot.
A fool and his hard drive are soon parted.
On the consumer side, AMD GPUs rock at double, while nVidia's suck.
Here's an example from TFA:
tan(1.5707963267948966193)
actual -39867976298117107068
x87 fpu -36893488147419103232
error 743622037674500958.81 ulp
You might take a look at the article and at Intel's reply.
The issue is in sine, cosine, and similar trig functions, with an actual error of 4e-21. That error scales, of course.
Intel's documentation change basically says you should scale and reduce your numbers first before running the functions.
Consider what that level of error precision means. If you were measuring with a meter stick, you could be measuring the radius of electron charge radii with several precision bits left over. If you were measuring the distance between the Sun and Proxima Centari, you could do it in millimeters and have accuracy to spare.
Even though I've run HPC simulations most of my career, we've seldom needed more than around six decimal digits of precision; that's akin to variations of human hair width when working at the meter level. It's only a problem when someone throws some strange scale into the mix; we're running physics on the kg-m-s scale, and suddenly someone complains that their usage of microseconds and nanometers breaks the physics engine We answer simply, "Yes. Yes, it does." If you need to operate in both scales, you need a different library that handles it.
Finally, even the actual article admits this is mostly about documentation. "The absolute error in the range I was looking at was fairly constant at about 4e-21, which is quite small. For many purposes this will not matter. ... for the domains where that matters the misleading documentation can easily be a problem." He then points out that a bunch of existing math libraries know about it. He mentions that high precision libraries have different solutions and always have. He mentions that most scientists who need it use better, high precision libraries. And he details that is really just the rough approximations done on the FPU that already plays fast-and-loose by switching between 53-bit and 63-bit floating point values that have been documented as being only good for that kind of approximation since the 1980s. Everybody who works professionally with floating point for any amount of time already knows the entire x86 family (including AMD and Intel) dating back to the original coprocessor are all terrible if you need high precision.
//TODO: Think of witty sig statement
Here's what the complaint is about: The Intel FSIN instruction performs an argument reduction to calculate the values of the sine function, but not with the exact value of pi, but using a 66 bit approximation of pi. If your argument is close to a multiple of pi, then the argument reduction doesn't give the correct result.
HOWEVER, if your argument is an extended precision number close to pi = 3.14..., then the last bit in the mantissa of that number has a value of 2^-62. So if you calculate an argument close to pi, the unavoidable bounds for the rounding error are 2^-63. This error in the argument is about 10 times larger than the error caused by using an approximation for pi in the argument reduction. If you use double precision, the error in the argument is about 20,000 times larger than the error caused by the argument reduction.
All this has been known for years; posting it today and claiming there is any problem is just ridiculous.
To be fair, almost no consumers have any use for double. And commercial entities who do usually don't mind the extra zero at the end of GPU's cost, because to them, that's just expenses to be written off on their taxes.