hobold (hobold@vectorizer.org) on 7/19/10 wrote:
---------------------------
>Linus Torvalds (torvalds@linux-foundation.org) on 7/19/10 wrote:
>---------------------------
>[...]
>>- the kind of code you talk about is such a small fraction
>>of the code any real CPU runs that it's not really worth
>>even bringing up as an argument.
>
>This is a judgement call, not an objective fact.

Sure. That said, I've written some code like that myself.

And the thing is, the simple cases, OoO really does not
lose any performance. You can hand-tune the assembly, and
an OoO machine will run it quite well, probably very close
to optimally.

The annoying case is when you have unreliable OoO. The
only such case I've personally worked with is the P4: the
performance profile is almost random, and small changes
can result in ridiculous performance anomalies that are
not at all obvious.

So I would almost agree with Ian if the choice was
between in-order and the P4 style OoO. But that's not so
much about OoO as about the fact that the P4 just did some
really odd things with store buffer replay microtraps etc.

And yes, there are always specific loads where any kind
of speculation bites you. Again, it's not so much OoO vs
in-order: even with in-order you'd want things like branch
prediction etc, and under very specific loads that will do
the wrong thing, and you may curse the CPU for being "too
clever".

But there really are very few cases where you have both
highly tuned code and don't care about more than
one single version of the microarchitecture. And are willing
to forego all compilers (maybe you have a "smart assembler",
that's been done several times).

Linus