By: Linus Torvalds (torvalds.delete@this.linux-foundation.org), July 2, 2013 12:12 pm
Room: Moderated Discussions
⚛ (0xe2.0x9a.0x9b.delete@this.gmail.com) on July 2, 2013 11:38 am wrote:
>
> Well, isn't it true that it is possible to utilize FP registers and FP logic in integer
> workloads? This would imply that basic FPU operations such as addition, subtraction,
> multiplication and comparison need to run about as fast as in the integer ALU. Moves
> between FP registers and [INT registers or memory] need to be fast as well.
That's particularly stupid.
Any CPU where FP addition is as fast as integer ops is a f*cking disaster. FP addition is fundamentally much more complicated than an integer add, and if that doesn't show up in timing, the CPU is pure and utter shit. It really is that simple.
And any language that cares about performance will do integer ops using the integer units for that reason.
Now, there are obviously interpreted languages where the costs are elsewhere, and you might as well do everything in FP and not have integer values at all, but that's not an argument for anything that has to do with performance.
The fact is, integer arithmetic is simply more important than FP. Your argument that you could do integer ops using the FPU is just completely moronic. Sure, you could do it, but you'd have to be a complete moron that doesn't understand how the world works and doesn't care about performance to do it.
Floating point is not only fundamentally slower and more complex than integer math, it's also fundamentally more likely to lead to bugs. The precision and underflow/overflow behavior of floating point is really really complicated, and easy to get wrong. To the point that it is not horribly uncommon to do the exact reverse of what you suggest: instead of using the FPU for integer math, lots of competent people use the integer unit for FP (where the "F" then is often for "Fixed", not "Floating").
Yeah, integer math has its own set of subtleties (overflow in particular), but then the catastrophic loss of value range often ends up making the bug more obvious than the very subtle loss of precision you hit with FP math.
That said, I do agree with you that you generally want to make FP value moves be fast as hell, and if they can avoid the FPU entirely, that's a good thing. It's a good thing if you have fast full-precision FP load/stores and FP register moves. Those should generally not even need to go through any FP unit, though. Handling FP register moves through renaming etc is a GoodThing(tm).
Linus
>
> Well, isn't it true that it is possible to utilize FP registers and FP logic in integer
> workloads? This would imply that basic FPU operations such as addition, subtraction,
> multiplication and comparison need to run about as fast as in the integer ALU. Moves
> between FP registers and [INT registers or memory] need to be fast as well.
That's particularly stupid.
Any CPU where FP addition is as fast as integer ops is a f*cking disaster. FP addition is fundamentally much more complicated than an integer add, and if that doesn't show up in timing, the CPU is pure and utter shit. It really is that simple.
And any language that cares about performance will do integer ops using the integer units for that reason.
Now, there are obviously interpreted languages where the costs are elsewhere, and you might as well do everything in FP and not have integer values at all, but that's not an argument for anything that has to do with performance.
The fact is, integer arithmetic is simply more important than FP. Your argument that you could do integer ops using the FPU is just completely moronic. Sure, you could do it, but you'd have to be a complete moron that doesn't understand how the world works and doesn't care about performance to do it.
Floating point is not only fundamentally slower and more complex than integer math, it's also fundamentally more likely to lead to bugs. The precision and underflow/overflow behavior of floating point is really really complicated, and easy to get wrong. To the point that it is not horribly uncommon to do the exact reverse of what you suggest: instead of using the FPU for integer math, lots of competent people use the integer unit for FP (where the "F" then is often for "Fixed", not "Floating").
Yeah, integer math has its own set of subtleties (overflow in particular), but then the catastrophic loss of value range often ends up making the bug more obvious than the very subtle loss of precision you hit with FP math.
That said, I do agree with you that you generally want to make FP value moves be fast as hell, and if they can avoid the FPU entirely, that's a good thing. It's a good thing if you have fast full-precision FP load/stores and FP register moves. Those should generally not even need to go through any FP unit, though. Handling FP register moves through renaming etc is a GoodThing(tm).
Linus
