no thanks (no@thanks.com) on 9/27/09 wrote:
>
>Does this line of thinking extend so that you now think
>doing Transmeta style translation machines are the wrong
>thing to do?

One of the things that my experiences at Transmeta convinced
me of is that doing in-order translation machines is
the wrong thing to do.

>That is, should OOO be only done in hardware rather than
>runtime software on an in-order uarch?

I think Transmeta did many things really well, and was
fairly good at capturing some "big pattern" dynamic behavior
and optimizing that at runtime with software. We did some
clever things, and I suspect JIT's with more degrees of
freedom (eg Java) can do even more.

But there is absolutely nothing you can do in software for
dynamic behavior that is on the scale of tens (or even
thousands) of cycles. Cache access patterns need OoO (or
at least some weaker form of it - maybe somebody makes a
good run-ahead engine).

Instruction scheduling likewise is about dynamic behavior
at a low level where software can't do the last details.
The compiler (static or dynamic) may do fine for linear
basic blocks without lots of cache behavior, and you can
extend those basic blocks with various tricks (predication,
unrolling, inlining), but most of those tricks have fairly
serious limitations and downsides to them. And none of them
make the problem go away in the end.

So I think JIT compiling is great. But in the end, you
still need dynamic hardware in addition to all the
things you can do in software.

Linus