Richard Cownie (tich@pobox.com) on 7/19/10 wrote:
>
>Sure. But it's a trade-off of silicon and power.

But that's only a valid argument if you are in a situation
where you don't have enough power and silicon to do OoO.

The thing I objected to was that Ian was essentially
arguing against OoO given that he had it. That means
that there is not any question about whether you have
the transistors or the power envelope to do OoO. So he
wasn't talking about some milliwatt part that did in-order
because it couldn't afford to do OoO.

He was saying that given OoO, he finds it a hindrance to
his performance work. Which is claim is basically always
total bullsh*t. Yes, OoO is often harder to analyze, the
same way caches make things harder to analyze, but that's
because it's more complicated. The code runs faster, and
in-order would make the problem of optimizing simpler, but
the end result would be slower.

Performance is tough. To get best performance, you need
to do complicated things. You need to accept the fact that
you need caching, you need out-of-order, and you tend to
often need fairly complex data structures with indexing,
locking and other fancy features.

Complaining about the fact that things get complex is
kind of pointless. Simplicity wouldn't get you to the
point you are aiming for.

(Of course, sometimes the answer is to make things
simpler, but that's because you made a mess of things, and
you need to start from the beginning. Complexity is not a
a-priori sign of high performance - but high performance
often does require complexity).

Linus