Linus Torvalds (torvalds@linux-foundation.org) on 7/19/10 wrote:
--------------------------
>
>Put another way: ants probably use a lot more neurons
>globally for their work than humans do. And they probably
>have affected the global ecosystem more than humans have
>had time to do. But there's still a purely qualitative
>difference between somebody having a conscious thought and
>lots of ants scurrying about.

Well, the past month I've been struggling to contain
hundreds of tiny ants invading my kitchen. It seems they're
smarter than me overall :-)

On the wider issue, it seems to me that OoO, together
with a memory hierarchy based on caches that operate
without (much) explicit software control, is absolutely
the right choice for systems where either a) you don't
know in advance what algorithms it's going to run,
or b) you know in advance what algorithms you're going
to run, but those algorithms have a fair amount of
unpredictable behavior (especially unpredictable memory
access patterns). That still leaves quite a few areas
where highly-tuned code on in-order cores, possibly
with explicit control of the memory hierarchy, can be
effective. Though since OoO uses more silicon and less
software effort, the long-term trends of hardware getting
cheaper while people get more expensive will keep
expanding the applicability of OoO.

Also software is going to (or at least *should*) evolve
in interesting ways in response to the rise of OoO
architectures. We have a whole lot of research into
algorithm and data structure design based on a 1960s/70s
model of machines where instructions are sequential
and expensive and data accesses are uniform and cheap.
And now the interesting OoO machines have instructions
which often go in parallel and are almost free, while
memory accesses are highly non-uniform and massively
expensive (e.g. 0.3nsec cycle time vs 100nsec DRAM
latency). You can get a good deal of mileage out of
designing fairly complex-looking data structures with
friendly cache behavior - e.g. packing data into
aligned 64B or 128B chunks to match the cache lines,
using hashing (traverse O(1) cache lines to get to the
data) rather than trees (O(logN) cache lines to get to
the data). And the the instruction-level parallelism of
OoO helps out too: if you need to look at 8*8bytes in a
cache line, you may be able to write it as non-dependent
instructions that end up executing in parallel.

In short, you *can* optimize for OoO machines, and get
a lot of mileage out of it. But it tends to involve
thinking at a higher level about the data structure
design, and then letting the OoO engine take care of
the cycle-by-cycle details.