Slashdot Mirror

← Back to Stories (view on slashdot.org)

Where Intel Processors Fail At Math (Again)

Posted by Soulskill on from the 1+1=3-for-sufficiently-large-values-of-1 dept.

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.

23 of 239 comments (clear)

  1. Intel Common Core i7 by Spy+Handler · · Score: 5, Funny

    with new maths

    1. Re:Intel Common Core i7 by Falos · · Score: 4, Funny

      1+1=3 for particularly large values of 1

    2. Re: Intel Common Core i7 by iggymanz · · Score: 4, Insightful

      what's the problem, 8 + 5 = 10, absolutely true in base 13

    3. Re: Intel Common Core i7 by Anonymous Coward · · Score: 3, Funny

      "'8 + 5 = 10' is True or false"

      Is True.

  2. What this mean... by __aaclcg7560 · · Score: 4, Interesting

    I should get an AMD CPU and put the extra money towards a graphic card since GPUs do math extremely well in parallel.

    1. Re:What this mean... by Austerity+Empowers · · Score: 3, Insightful

      I would test that theory first. I have a hunch some GPUs are going to take shortcuts with math that someone like the guy who wrote this article will object to.

    2. Re:What this mean... by rasmusbr · · Score: 4, Insightful

      AMD CPU:s reportedly return exactly the same values as Intel CPU:s. I'm guessing they do so for compatibility reasons, so that any workarounds that software developers have implemented work as expected.

    3. Re:What this mean... by sexconker · · Score: 4, Informative

      On the consumer side, AMD GPUs rock at double, while nVidia's suck.

    4. Re:What this mean... by ais523 · · Score: 4, Interesting

      GPUs used to take mathematical shortcuts all the time. More recently, though, with the scientific community starting to use GPU clusters for computation, the main GPU manufacturers have been adding mathematically precise circuitry (and may well use it by default, on the basis that there's no point in having both an accurate and an inaccurate codepath).

      --
      (1)DOCOMEFROM!2~.2'~#1WHILE:1<-"'?.1$.2'~'"':1/.1$.2'~#0"$#65535'"$"'"'&.1$.2'~'#0$#65535'"$#0'~#32767$#1"
    5. Re:What this mean... by Frobnicator · · Score: 5, Informative

      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
    6. Re:What this mean... by Luckyo · · Score: 3, Informative

      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.

  3. Exact mathematical value isn't the ideal by i+kan+reed · · Score: 4, Insightful

    The main goal for Floating Point coprocessor sine calculations is to get a good enough result in a set number of cycles.

    Given that fully approximating sine takes about as many concrete operations as bits in the value, getting it exactly right isn't usually a trade off people want to make.

    There's a reason the C standard specifies that mathematical trig functions are platform dependent. If you want it precise, do it yourself to the level of precision you need.

    1. Re:Exact mathematical value isn't the ideal by TWX · · Score: 5, Insightful

      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.
    2. Re:Exact mathematical value isn't the ideal by Beck_Neard · · Score: 5, Informative

      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.
    3. Re:Exact mathematical value isn't the ideal by Anonymous Coward · · Score: 3, Interesting

      The problem isn't caused by the actual sine calculation, but in the preparatory range reduction, where the input value is mapped to the +-PI/2 interval. It appears that a "hard coded" approximate value of PI is the culprit, because the approximation is only accurate to 66 bits, but for the correct result, it would have to be correct to 128 bits. AMD at one point made processors which used the full precision value of PI and returned correct results for fsin(x). It broke software, so AMD "fixed" it by breaking it in microcode. AMD now uses the same less accurate approximation of PI and returns the exact same wrong values for fsin(x), even though they know it's wrong and already had the correct implementation. Processor cycles don't come into it.

    4. Re:Exact mathematical value isn't the ideal by ledow · · Score: 4, Interesting

      Sorry, but anyone relying on this for scientific use where the answer matters should be using software that gives them the accuracy they want and - ultimately - are the only people who will realise whether the result is correct "enough" or not for their process.

      Some idiot researcher who expects Excel or an FPU instruction to be accurate for sin to more than 10 decimal places is going to crop up SO MANY anomalies in their data that they'll stick out like a sore thumb.

      Nobody serious would do this. Any serious calculation requires an error calculation to go with it. There's a reason that there are entire software suites and library for arbitrary precision arithmetic.

      I'm a maths graduate. I'll tell you now that I wouldn't rely on a FPU instruction to be anywhere near accurate. If I was doing anything serious, I'd be plugging into Maple, Matlab, Mathematica and similar who DO NOT rely on hardware instructions. And just because two numbers "add up" on the computer, that's FAR from a formal proof or even a value you could pass to an engineer.

      Nobody's doing that. That's why Intel have managed to "get away" with those instructions being like that for, what? Decades? If you want to rotate an object in 3D space for a game, you used to use the FPU. Now you use the GPU. And NEITHER are reliable except for where it really doesn't matter (i.e. whether you're at a bearing of 0.00001 degrees or 0.00002 degrees).

      Fuck, within a handful of base processor floating point instructions you can lose all accuracy if you're not careful.

  4. Bad intel by Tablizer · · Score: 3, Funny

    We already know it's a sin to eat pi.

    --
    Table-ized A.I.
  5. Read TFA. Not even a close approximation, and docu by raymorris · · Score: 5, Informative

    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.

  6. Inaccurate headline by Loki_1929 · · Score: 4, Informative

    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."
  7. Re:Say what? by serviscope_minor · · Score: 4, Funny

    We are pentium of borg. Division is futile. You will be approximated.

    From what I remember it was the first revision of the Pentium 1 aka the Pentium 0.999998163849

    --
    SJW n. One who posts facts.
  8. example from TFA. try it by raymorris · · Score: 3, Informative

    Here's an example from TFA:

    tan(1.5707963267948966193)

    actual -39867976298117107068
    x87 fpu -36893488147419103232
    error 743622037674500958.81 ulp

  9. Re:My workaround by lgw · · Score: 4, Funny

    The positive or the negative root?

    I just use the average of the two, for predictable output.

    --
    Socialism: a lie told by totalitarians and believed by fools.
  10. Total rubbish article by gnasher719 · · Score: 4, Informative

    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.