5 ms·
>Float32 operations often require less CPU cycles as they need less precision. I guess that's true on mobile platforms? My understanding is that on modern desk
by mistercow 13y ago
>Float32 operations often require less CPU cycles as they need less precision.
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.
- carterschonwald 13y agoFor 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
- mistercow 13y agoRight, 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.
- carterschonwald 13y agoGood point. Are there any good examples that show case this?
- kevingadd 13y agoFP64 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.
- mistercow 13y agoThose 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.
- deleted 13y ago[deleted]
- mistercow 13y agoLike I said in another reply, I'm talking about the specific claim that float64 ops take more CPU cycles. There are other ways for them to still be faster, like caching.
- andhow 13y agoReferring to http://agner.org/optimize 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.
- Dylan16807 13y agoBut if your code vectorizes, can't you get twice the throughput on sections?
- andhow 13y agoAgreed, I was just replying to the OP that, even on desktop using scalar ops, there are advantages to single vs. double precision ops.