5 ms·

> Run some FP calculations on an AMD CPU and then an Intel CPU you'll get slightly different results. Are you saying that the exact same x87 or SSE instruction

> Run some FP calculations on an AMD CPU and then an Intel CPU you'll get slightly different results. Are you saying that the exact same x87 or SSE instruction sequence will yield different results on AMD vs Intel? As far as I know that isn't true and would be a very serious CPU bug.

edge17 15y ago
IEEE 754 floating point isn't associative
- psykotic 15y ago
  Next you are going to tell me the moon isn't made out of cheese. No, really, that's why I said I was talking about a specific machine code instruction sequence.
vilhelm_s 15y ago
IEEE specifies exact rounding for +,-,*,/ and sqrt, but it allows the transcendental functions to be inaccurate in the least significant bit (creating a fast exact algorithm for these is apparently quite hard). At one job, we were running our test suite on both Pentium4 and Athlon machines, and got into trouble because the exp() function returned different values about once every 10,000 numbers. We changed the regression tests to add a fuzz factor to the floating-point comparisons.
- edge17 15y ago
  yea, I've encountered this before while diffing outputs of two versions of the same thing (like a testbench to compare behavioral code vs netlist vs c simulation). In fact, this is one of the challenges in doing relational databases on gpu hardware. With relational databases you want to make sure the result of the same query is the same across every run. Relational databases are otherwise perfect use cases for gpu type of parallelization - i.e. running large numbers of parallel, read-only lockless operations without cross dependencies (for the most part, for most relatively simple queries)
- psykotic 15y ago
  Your point about IEEE transcendentals is a good one, and it ties into the so-called tablemaker's dilemma. But this isn't just an IEEE issue since we're talking about specific CPU-level instruction sets. I'd be surprised if AMD wasn't precision-compatible with Intel on x87 and SSE at the lowest level. Were you writing x87/SSE instructions using assembly code or intrinsics so you're sure the same instruction sequence was being generated in both cases of the example you mentioned?
  - vilhelm_s 15y ago
    The same binary gave different outputs depending on what CPU you ran it on.
    - psykotic 15y ago
      Interesting, thanks for the confirmation! I'll have to try to replicate that.

edge17 15y ago

IEEE 754 floating point isn't associative

psykotic 15y ago
Next you are going to tell me the moon isn't made out of cheese. No, really, that's why I said I was talking about a specific machine code instruction sequence.

vilhelm_s 15y ago

IEEE specifies exact rounding for +,-,*,/ and sqrt, but it allows the transcendental functions to be inaccurate in the least significant bit (creating a fast exact algorithm for these is apparently quite hard). At one job, we were running our test suite on both Pentium4 and Athlon machines, and got into trouble because the exp() function returned different values about once every 10,000 numbers. We changed the regression tests to add a fuzz factor to the floating-point comparisons.

edge17 15y ago
yea, I've encountered this before while diffing outputs of two versions of the same thing (like a testbench to compare behavioral code vs netlist vs c simulation). In fact, this is one of the challenges in doing relational databases on gpu hardware. With relational databases you want to make sure the result of the same query is the same across every run. Relational databases are otherwise perfect use cases for gpu type of parallelization - i.e. running large numbers of parallel, read-only lockless operations without cross dependencies (for the most part, for most relatively simple queries)
psykotic 15y ago
Your point about IEEE transcendentals is a good one, and it ties into the so-called tablemaker's dilemma. But this isn't just an IEEE issue since we're talking about specific CPU-level instruction sets. I'd be surprised if AMD wasn't precision-compatible with Intel on x87 and SSE at the lowest level. Were you writing x87/SSE instructions using assembly code or intrinsics so you're sure the same instruction sequence was being generated in both cases of the example you mentioned?
- vilhelm_s 15y ago
  The same binary gave different outputs depending on what CPU you ran it on.
  - psykotic 15y ago
    Interesting, thanks for the confirmation! I'll have to try to replicate that.