>>>>>Which part of OoO stuff imposes a hard limitation on
>>>>>clock rate, hittable by an in-order chip, yet unhittabble
>>>>>by an ooo chip?
>>>>
>>>>That would be the scheduler.
>>>
>>>I seriously doubt it.
>>>
>>>The truly critical part tends to be the memory pipeline,
>>>with the L1 cache in particular. And OoO allows for rather
>>>greater flexibility in that area. An in-order chip with a
>>>3-cycle L1 latency is horrible crap.
>>
>>Is this really true? It's that hard for a compiler to schedule loads ahead of use?
>>For a wide core like ia64 it *is* a lot of instructions. But a narrower core running
>>at higher frequency could schedule around a higher latency L1 cache.
>
>Have you ever tried it? It's hard enough scheduling for a 1 cycle load-use latency,
>especially if we're talking 2-way or wider. Anything beyond that, and it's hopeless
>- there simply aren't enough independent instructions or registers available. Sure,
>there are a few loops that can be scheduled perfectly (things like dotproduct), but typical sphaghetti code can't.

Thats the first time I heard that IA-64 doesn't have enough registers ;)
Anyway, the big part of doing it is converting spaghetti to something nicer, in which the predication is the key, whether is in form of cmov or generic like IA-64.
Scheduling for inorder x86 for longer L1 latency is more interesting issue, due to low number of registers, and only cmov, and tricks that simply are not generic enough to be put in compilers, and x86 assembler use is pretty much dead.
The conversion to something nicer gives nice performance boost even without scheduling for L1 latency.

>>> While a OoO design
>>>with 4-cycle latency is potentially fine.
>>>
>>>So the whole "OoO reduces frequency" argument is bogus and
>>>totally retarded. It's also not backed up by most real life
>>>designs out there, afaik. OoO chips tend to be clocked at
>>>a higher frequency. And that's not just because they are
>>>higher-end. Just look at microarchitectures from the same
>>>vendor (big hint: Intel. Look at what clocks high, and
>>>what still doesn't - after decades of wasted work).
>>>
>>>So yes, I'm sure that in an OoO design, there are paths
>>>that are nasty. And I'm sure the instruction scheduler is
>>>part of it. But anybody who claims that OoO reduces the
>>>available frequency had better back that up with some real
>>>examples, because quite frankly, reality seems to argue
>>>against it.
>>>
>>>(Yeah, there's POWER6 and it's "limited in-order", but it's
>>>actually ooo in the memory pipeline - it's just that all
>>>the ALU ops are in-order, the memory pipeline schedules
>>>independently of the ALU/branch pipelines iirc, and the
>>>memory pipeline is out-of-order, I think)
>>
>>But it will still have to stall waiting for ALU ops to complete if they depend
>>on an outstanding load, no? It has some runahead, but this is still presumably only
>>fetching into L1 cache. So the L1 load to ALU use is still problematic isn't it?
>
>Only pointer chasing code will notice L1 latency. In other cases the latency will
>be hidden as long as there are enough rename registers and other buffers. Note also
>that an OoO pipeline can reorder loads and stores as it knows the actual addresses,
>this is something software can't do because of aliasing.

Thats why IA-64 has ALAT for doing it, IA-64 can do that in software, with SOME hardware assist. Too bad the hardware costs for doing it are prohibitive, and probably one of the reasons why IA-64 is low clocked. Basicly they can predict no conflict in addresses, and then jump to fix code if hardware detects that it conflicts.

The big thing is IA-64 has all the OoO hardware that OoO CPU:s are but they are just software visible, and used totally different way.
Register renamers, ALAT tables...