>>>200 MHz @ 0.35 um, 81 sq.mm, 4/5 W typ/max
>>>300 MHz @ 0.29 um, 42 sq.mm, 4/6 W typ/max
>>
>>600 MHz @ 0.35um EV56
>>And intel got 300MHz @ 0.35 (klamath)
>>
>>So PPC WAS lower clocked, due to fact it was short pipeline.
>>So it isn't really a proof that with OoO you can have both short pipeline AND clock it high.
>
>Logic reasoning and facts are hardly friends of yours, ain't they? You mention
>Alpha; it clocked at ~600 MHz in 0.35 um for both '164 and '264 (IIRC 575 MHz),
>same pipeline length, and it was way above *anyone else* in the industry, in-order or OoO, wasn't it?

EV6@EV5 had different pipeline length atleast from fetch to execute. EV5 started execute in stage S4 and EV6 in stage S5, also EV5 has extra stages that are not necessarily required in simple inorder pipeline, but are beneficial.
First is buffer stage, which basicly separates execution from instruction fetch, just like issue buffer in OoO chips but is fully inorder.
And slotting stage which is not required if A) each pipeline could execute any instruction, B) in VLIW design.
So from EV5->EV6 transition I can argue that OoO lengthens the pipeline by stage or 3.
I didn't check your assumptions on their pipeline lengths until now when I was wondering why EV5 would have such a long pipeline, and answer was that it didn't it was 1 cycle shorter than EV6 pipeline.

[ev6 pipeline from here]

http://realworldtech.com/page.cfm?ArticleID=RWT101600000000&p=2

EV5 pipeline from here
http://www.cis.upenn.edu/~cis501/papers/Alpha21164.pdf

>Besides, as for Klamath, sandpile states very explicitly that it was fabbed in 0.28 um process. Is this wrong?

http://www.pcguide.com/ref/cpu/fam/g6PII-c.html

And some others mention it as 300Mhz version...


>>600MHz VS 200Mhz is far lower, and 300mhz is compared to other OoO designs of same
>>process node. So it PPC WAS clocked far slower than other designs on given process node.
>
>If sandpile is right, PPC603 clocked at *exactly the same* rate as both P5 and
>P6 on the same process node. And Alpha lost a little in clock rate (for unknown
>reason btw; could be thermals) going ooo while keeping #stages the same.

Alpha got far more aggressive in circuit design and their paper says THAT.

>>Basicly OoO requires extra work BEFORE some work that is done on both OoO and inorder
>>machine, and some work AFTER the decode but before execute, that inorder design
>>you could sometimes put in parallel with execute...
>>That means you have longer dependency chain in OoO pipeline.
>
>Isn't it possible to do at least some of ooo stuff (and maybe most of it) largely
>"in parallel" to an otherwise similar in-order pipeline? Because judging from same-length
>pipe for EV5 and EV6 it appears to me to be the case. And mentioned PPC603 had 4-stage
>pipeline (vs. 5 or more for several other in-order machines). What is/are the extra stages in PPC603 due to ooo?

PPC603 doesn't really have much of a OoO features.

>BTW, you should be able to easily find a confirmation that PPC603 (which clocks
>at exactly the same rate as P5 and P6 if sandpile is correct about process) is a
>4-stage machine: fetch, decode+isue, execute, complete+writeback. I wonder if you
>can find a source that states something different.

Nope. But PPC603 was barely OoO. It could execute or stall ONE instruction per execution unit, so a single instruction that didn't have an inputs ready would stall the execution unit. With sole exception of memory unit that could chooce from TWO instructions. It was almost inorder pipeline.

>>Its power costs, is about 27% by EV6 pipeline power consumption diagram, just for
>>selecting the next instruction. And power limits todays designs...
>
>And I don't recall Alpha designers stating any other
>design objectives other than performance leadership.

Nope, but EV6 did have power efficiency in account because they couldn't cool the chip if it would of had higher power consumption, so they did work the power efficiency to reduce it power consumption from beyond something they could cool or supply power to a level which was manageable, in order to keep the clockspeed...

>>>are somehow limited in terms of clock rate because of OOO? This I would find extremely
>>>questionable. More likely the machine's cycle time was tuned to the timing of ALU
>>>units and their bypass network; maybe L1d, or maybe both of them. That is to say,
>>>I don't believe that the machine's clock is limited by ooo, show some proof for that.
>>
>>Intel showed its ALU components in technical papers running MUCH higher frequency
>>than they ever got in P4.
>
>Yes, there were such papers, but are you sure the papers you're referring to discuss
>Pentium4's ALUs for 0.18um and 0.13um as I asked, not later processes, or specifically
>designed ALUs, which may not be practical for a high-volume x86 chip at all?

Maybe it was practical, maybe it is, checking it again isn't on my list of things I need to do.

>And do you think 0.18/0.13 P4 could clock higher w/o going for a 3-cycle L1D even if it's not ALU-limited?

It was TINY L1D cache. It had far LOWER than 3 cycle latency in northwood.


>You know, I can't help mention Itanium here. It never had a dynamic scheduler (it
>does have some pretty interesting logic in memory pipe, and this is one of the things
>I never really understood about Itanium -- having a "smart" ISA which allegedly
>alleviates the need for OoOE, and yet design cores which nooned would call simple
>or lightweight). And look at the clocks and power.

Itanium had OoO memory pipeline, and register renamer. So it got power consumption of OoO chip structures, while showing programmers an inorder chip. Not a good design decision.



>>But OoO logic costs power 30% in this case. Another nice case is that ALL integer
>>execution units combined costs 10% of the power, which is pretty much place where I would prefer doubling it...
>
>Then let me ask you something, Jouni. Are you a big believer in in-order for general-purpose
>processing, or some kind of UNbeliever in OoOE, despite all the facts mentioned
>in this thread and, I'm sure in tens of much more interesting and technically richer
>discussions at RWT and maybe other boards? Do you think that in-order (or maybe
>Itanium) will one day deliver cores which will make people mark OoO as a dead end
>in computer architecture and go back to in-order machines which will get wider and
>wider, higher- and higher-performing, as Itanium bonzos seemed to promise IIRC? What is it?

I don't believe OoO is free, I believe that its one heck of a costly method that is absolute MUST if you have legacy code bases that you need to run really fast. It costs in many different ways, but its quite often worth it. However, if you want absolute maximum performance and can spend time optimizing code inorder is better, but only if it avoids several pitfalls that both SUN and Intel made with their 64bit ISA definitions. Itanium is definitely a not answer, it has the OoO structures in inorder pipeline consuming power there.


>
>This is much more admitting and moderate viewpoint.

I ALWAYS had moderate viewpoint, MY viewpoint is that OoO has lots of real costs, and its sometimes worth it and sometimes not, and trying to rebuke that OoO is really a free ride for performance or that OoO is magic bullet that is optimum always, which it clearly isn't.

>Actually, in case you really don't appreciate how efficient some ooo implementations
>are, why don't you take a closer look at said PPC603, namely its transistor budget,
>wattage and performance? Not necessarily for the sake of argument, but simply to
>appreciate it? Esp. how they compare with competitors. Design teams are different;
>merits of particular implementation styles should be judged by the best representatives for objectivity.

PPC 603 is almost inorder machine what they give, It doesn't select anywhere which instruction to execute next (except having one slot for selection in load/store unit)
It really doesn't bring much of the OoO benefits, nor its costs.

>Not only that, but also between someone who bases his statements on facts and references
>and asks the other for proof, and someone who makes a lot of statements and repeatedly
>fails to back his claims.

Basicly two problems, I don't keep list of references for facts that I've learned over long time. Second I just assumed you would notice that you need to know address of a value before you can start loading value from a location like a register file ;)
I just assumed you had some of the background knowledge I had, after which it should be obvious.