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.

Comments

What this mean...

[__aaclcg7560]

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

Re:What this mean...

[hairyfeet]

That is what I've been telling folks here for years, the bang for the buck is still in the AMD camp and with their new GCN arch you can use the GPU for the heavy FP math which beats the FP in any CPU by a country mile so there really ain't any point in putting a bunch of heavy FP in the CPU anymore.

As you can see the difference in number crunching between Intel and AMD in real world applications is crazy low, we are talking around 10%-15% max and that is if you go top o' the line Intel. Now I don't know about you but 15% boost isn't worth 300% markup in MY book. Oh and before anybody brings up benchmarks? As the guy in the video points out benchmarks have been rigged with Cinebench recently being caught putting "If CPU is AMD, tie boat anchor" code into their benchmark and this of course doesn't even mention the Intel Cripple Compiler which to this very day cripples any program compiled with it. At the shop I have done just like in the video and run real applications and compared, the result? Just as he found, the difference is so small you wouldn't be able to tell without breaking out a stopwatch...but your wallet knows, especially when you can get a hexacore for $105 and an octocore for $130.

So if you are wanting just a good office style box I'd go with good number crunching something like A8 6600K APU kit for $210 after MIR or if you want a good entry level that you'll add your own GPU the fx4200 quad kit for $190 after MIR is a great price, but personally? I really like the FX6300 hexacore kit for $270 after MIR. Its a great price, the chip has plenty of power and headroom to OC if you are into that, and with turbocore its like getting 2 chips, a 3.5GHz hexa and a 4.1Ghz triple, its just a really solid chip.

Re:What this mean...

[ais523]

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).

Re:What this mean...

[hairyfeet]

To steal a line from mel brooks "bullshit bullshit aaaannnnddd bullshit". if you look at the actual figures it would take you 18.9 years to break even when comparing an AMD OCTOcore to an 4770k...now are you REALLY gonna be using that 4770k 19 years from now? Didn't think so.

Sorry but the actual math shows that is a bunch of bull, you can't even buy a pizza with the amount you'd "save" by going intel, and the amount you'd lose in price difference means you would NEVER break even.

Re:Exact mathematical value isn't the ideal

[Anonymous Coward]

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.

Re:Exact mathematical value isn't the ideal

[ledow]

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.