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.
with new maths
From what I gather, the problem is that Intel didn't acknowledge in documentation how poor the instruction was for scientific use though. This is fine for home and probably most general-purpose business use, but becomes a problem when it's more critical. If those that develop software that relies on sine functionality don't know about this then error in the results of their programs will actually matter.
This won't matter to a gamer playing some first-person shooter.
Do not look into laser with remaining eye.
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 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.
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