Efficient float32 arithmetic in JavaScript(blog.mozilla.org)
blog.mozilla.org
Efficient float32 arithmetic in JavaScript
https://blog.mozilla.org/javascript/2013/11/07/efficient-float32-arithmetic-in-javascript/
1 comments
For CPU instructions yes, but for derived operations that are usually running a few steps of a newton methor or taylor series, those probably converge faster to Float32 precision than Float64 precision
Right, that was what I was saying in my second part. But they won't reach 32 bits of precision faster (they might actually reach it faster with float64, since each step is more precise). And if you only need 32 bits of precision, there's not much difference between accepting 32 extra wrong bits, and rounding the number down to 32 bits.
Good point. Are there any good examples that show case this?
Referring to http://agner.org/optimize, both Nehalem (Intel Core i7) and Jaguar (AMD Kabini) instruction tables: you are right that addss, subss show the same latency as addsd and subsd, resp. However, mulss and divss show better latencies than mulsd and divsd.
But if your code vectorizes, can't you get twice the throughput on sections?
Agreed, I was just replying to the OP that, even on desktop using scalar ops, there are advantages to single vs. double precision ops.
[deleted](1)
FP64 is more expensive on GPUs than FP32 (the cost gap depends on the particular architecture, but I've seen 1/8 and 1/4 ratios listed for recent parts) - so even if all modern desktop CPUs don't pay an extra cost for FP64, it's still worth thinking about the size of your floats for GPU compute.
Also, it's important to keep in mind that even if the cycle count is the same, you're using twice as much memory which means you're occupying twice as much space in cache. If your buffers suddenly get twice as large to represent the same data, that's going to negatively impact performance, just like how 64-bit pointers result in a perf penalty vs 32-bit pointers. If everything stays in registers you're probably fine, since those are all fixed-size and usually have more than enough space for a few 64-bit floats.
Also, it's important to keep in mind that even if the cycle count is the same, you're using twice as much memory which means you're occupying twice as much space in cache. If your buffers suddenly get twice as large to represent the same data, that's going to negatively impact performance, just like how 64-bit pointers result in a perf penalty vs 32-bit pointers. If everything stays in registers you're probably fine, since those are all fixed-size and usually have more than enough space for a few 64-bit floats.
Those are good points. I think the other points the article makes are valid too. Again, I was just taking issue with the specific claim of "CPU cycles". I think it's important because thinking CPUs still work the way they did 15 years ago is a common source of premature optimization.
I guess that's true on mobile platforms? My understanding is that on modern desktop CPUs, the only time double precision takes more CPU cycles is if you're doing SSE (since you can't fit as many doubles into an SSE register).
And I suppose in some contexts where you have to compute a value iteratively, you'd have to do more iterations to get full precision out of a double. But the situations where you really care about having an actual float32 instead of simply letting the trailing bits of the float64 be incorrect are relatively rare.