Ian Ollmann (iano@apple.com) on 7/19/10 wrote:
>
>I personally find the OoO engine to be a bit of a hinderance to performance. Its
>great for the massively overwhelming amount of code out there written with a C/C++
>compiler with not too much thought to performance. (read: 99.99%+ of code) There,
>you might get 10% of peak instead of 3% of peak. However, when you are trying to
>get the last drop out of the architecture and are willing to go to assembly, something
>with a simpler execution engine, typically an in order machine with non-destructive
>ISA, is far easier to take to close to peak performance.

Umm. That may be true, because it's clearly easier to tune
something that is simpler and more deterministic. However,
you are making a silly argument for two reasons:

- 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.

- even for the kind of code you talk about, that elusive
"peak performance" is likely higher with OoO!

So your argument that you can get 'closer to peak' is kind
of pointless, if 'closer to peak' is still slower on
an in-order part.

In fact, your argument is the exact same argument that
people used to use against caches. The caches make it much
harder to get "peak" performance, because suddenly the
actual performance depends a lot on things like data
structure layouts etc.

So without caches, you can tune your algorithm at the
assembly level, and you can pat yourself on the back and
tell yourself "this cannot be done faster". With caches,
that suddenly becomes much harder, because the fastest
code sequence often depends on which parts were still in
cache when the function was called etc etc.

So cacheless CPU's can be tuned much better. But who the
f*ck cares whether you can get to 80% of peak, or 100% of
peak, when the "100% peak of non-cached" value is way way
less than "80% peak of something with a cache".

The exact same is true of OoO. Your "it's harder to
tune" argument is as invalid today as it was 30 years ago,
despite being totally true.

The thing is, when you have non-uniform timing, OoO helps.
And there are basically zero loads that don't have
that. You have differently sized caches, you have memory
subsystems that are not the same speed etc etc.

That theoretical "peak" thing only exists on a single
machine with a very particular setup. If you change any
of the details, your optimized routine may no longer be
optimal, because now the optimal scheduling is different.

And that's where OoO helps. It helps with things like
different L1 cache latencies in different implementations.
It helps with having different L1 (or L2) sizes. It helps
with slightly different branch predictors etc.

Without OoO, you can never have something robust.
You end up having to tune your code for one particular
machine, and five years from now when that machine no
longer exists, you're basically screwed.

In other words, your argument is pure and utter garbage.
It's "true" only in a trivial and totally idiotic way.
Because if the code is so important that it is worth tuning
for at an assembly level, it's so important that it will
run on machines for longer than one generation or on many
different versions of a similar machine.

At which point you'll want OoO. Really. Because in-order
will screw you up.

Linus