Linus Torvalds (torvalds@osdl.org) on 10/27/06 wrote:
>
>My argument comes down to the fact that "robust" actually
>ends up being faster.

Btw, I realize that you probably won't understand my
argument, but it's not that it's always faster at any
particular point: at any particular point you can
probably correctly argue that "if we expose xyz and let
software handle it manually, the software people can do
it better than our current microarchitecture".

So yes, there will always be a "true" argument that some
particular choice was correct at that time.

My whole robustness argument has none of that. It
says that "any particular time" is much less important than
"in the long run".

And robust choices are better in the long run, exactly
because you don't know what you can do. If you did
know what you could do, it wouldn't be "high tech" any
more. It would be just bulk engineering, with nothing
left to discover - just shrinking stuff purely for price.

Maybe we'll get to that point. Maybe it's even getting
close. I don't think it's here yet.

So what I'm saying is that making architecturally visible
choices until you hit the point where you know
everything is actually a really bad idea. Until then,
you're actually better off with "robust": trying to not
expose the special cases at all, but just handling them
all.

For an example of this, take the IEEE FP hardware. Intel
actually really did the right thing in doing it all "in
hardware", even though a lot of it was hidden behind
microcode. In fact, over the years, x87 FP has gotten
more generic, in that now things like sin/cos do
not need the argument range reduction they originally
needed.

Everybody else said "we don't want to handle this". And
everybody else was wrong. The x87 actually did the
right thing. You can do full-precision transcendentals
at high performance without any extra strange
architecturally visible guard bits or other crud, and they
didn't need to make their architecture uglier for it. Each
microarchitecture can choose how they implement
the correct rounding, and what algorithm to use, without
being forever shackled to some specific one that was done
in software and as a result lives on forever.

End result? Last I saw, x86 simply was faster. Not just
for the special cases. For all the normal cases too.

(And yes, effort is part of it, and success breeds success.
But part of that "breeding success" has been "friendly to
software", and not playing any idiotic games. Again: the
robust and simple approach actually wins).

Linus