4 ms·
The Cray 1 was done before anyone realized the importance of denormals. And denormals are gruesome to implement on vector machines anyway.
by dbcurtis 10y ago
The Cray 1 was done before anyone realized the importance of denormals. And denormals are gruesome to implement on vector machines anyway.
- greglindahl 10y agoOnly a subset of scientific codes benefit from denormals, and it does not appear that implementing them is that big of a deal, given that 4-stage pipelines can do it. The pipeline depth to memory is a lot bigger than 4.
- dbcurtis 10y agoIf you consider every iterative algorithm that solves systems of nonlinear equations a subset you cam ignore.... SPICE, linpack, fishpack.... sorry, denormals are essential to today's algorithms. As to "no big deal".... show me your code. Don't worry, I'll be able to understand it. After 20 years as a CPU designer I've learned how to understand bit-bashing.
- greglindahl 10y agoThe iterative algorithms for all of the scientific fields that I've worked on don't fall within the subset that you're describing, so no, I'm not going to agree that you're speaking about the majority of today's algorithms. Weather, climate, finite differencing, FFT... nope. Implicit systems, sure. Radar cross-sections, sure. And as a CPU designer, are you disagreeing that most FP units today take 4 cycles (fully pipelined) (add and multiply, of course)? And that main memory is a lot farther away than that? Given 20 years of experience, you missed out on the Cray PVP machines that were the start of this sub-thread. But the cycle counts I'm giving are modern ones. Cray did eventually implement IEEE in these machines without any significant problems, but that was more than 20 years ago.
- nkurz 10y agoOnly a subset of scientific codes benefit from denormals, and it does not appear that implementing them is that big of a deal, given that 4-stage pipelines can do it. Maybe I'm misunderstanding your terminology, but it seems like you are saying that operations involving denormals have the same latency as normal floating point multiplications and additions. At least for multiplication on Intel chips through Haswell, I think the current case is that subnormals between 0 and FLT_MIN still have abysmal performance --- 100+ cycles of penalty. Here's Bruce Dawson from a few years ago: Performance implications on SSE Intel handles NaNs and infinities much better on their SSE FPUs than on their x87 FPUs. NaNs and infinities have long been handled at full speed on this floating-point unit. However denormals are still a problem. On Core 2 processors the worst-case I have measured is a 175 times slowdown, on SSE addition and multiplication. On SandyBridge Intel has fixed this for addition – I was unable to produce any slowdown on ‘addps’ instructions. However SSE multiplication (‘mulps’) on Sandybridge has about a 140 cycle penalty if one of the inputs or results is a denormal. https://randomascii.wordpress.com/2012/05/20/thats-not-normalthe-performance-of-odd-floats/ https://randomascii.wordpress.com/2012/05/20/thats-not-norma... And here's the overview from a slightly more recent paper: C. Subnormal Performance Variability Due to the complex nature of the floating point numbers, processors struggle to handle certain inputs efficiently. In particular, it is well understood that operating on subnormal values can cause extreme performance issues, including slowdowns of up to 100× [19]. As an example, on a Core i7 processor using SSE instructions, performing standard mul- tiply between two normal numbers takes 4 clock cycles, whereas the same multiply given a subnormal input takes over 200 clock cycles. https://cseweb.ucsd.edu/~hovav/dist/subnormal.pdf https://cseweb.ucsd.edu/~hovav/dist/subnormal.pdf Are you saying this has been fixed in recent (or non-Intel) chips? Or maybe you were considering only NaN and Inf when you said denormals?
- greglindahl 10y agoSorry, you're correct, I was thinking about the speed of NaN and Inf.