Jukka Larja (roskakori2006@gmail.com) on 9/21/09 wrote:
---------------------------
>AM (myname4rwt@jee.male) on 9/21/09 wrote:
>---------------------------
>
>>You don't get it at all, do you? :)
>
>I don't think you have gotten any of the discussion. It is obvious that Jouni has
>been talking from theoretical standpoint.

Theoretical standpoint, you say? :) Sound like a lame excuse to me in this discussion. Don't get me wrong, I tend to like theory and respect people who are behind it -- in general. But I suggest you should consider for a moment that as long as we talk *engineering* theory, then a perfect match with practice exists only when theory takes damn good account of the realities that engineers (the doers) have to deal with.

Remember Chernobyl? I wouldn't be surprized if *theoretical* design of the reactor core was done by people who earned all possible distinctions in the USSR, maybe even members of Academy of Sciences. And from *theoretical* point of view, their core could have been an excellent, very efficient converter of U-238 to Pu-239 when manufactured to highest standards and operated strictly at its design point. But the reality is such a bitch, it tends to spoil nice theory in every conceivable way; what must be straight comes out bent or curvy, power network demands that power output must be varied in acc. w/ consumption, burnout rate is not quite as even and constant across the core as it looks on paper, esp. when equations demand it to be constant in order to be solvable in a neat analytical manner :) etc. etc.

I could go on, but hopefully the point is clear; referring to theory to make up for fishy claims is a sad excuse.

Sure, you have pulled him in with some
>idiotic comparisons of real chips, but the fact is that no one has ever made an
>out-of-order chip by taking and in-order design and slapping out-of-order on it.
>
>You simply can't do that. Trade offs (performance, especially on certain workloads,
>cache latency etc.) become very different, so it would be insane not to redesign
>rest of the chip. On top of that, you probably aren't doing both designs at the
>same time with the same resources, so any advances in low(er) level circuit technologies
>are further going to blur the picture.
>
>But you probably know this full well yet still keep demanding proof.

Sorry, but I don't think proof is the right word. I would be really curious to see at least *anything* which would look good for his points -- and this is his job to bring it up. Besides, much of what you say is not what I ever asserted.

It was actually me who pointed out some of this early on to him, for counter-examples to his statements are abound, but I fully agree they can't really serve as counter-proof -- that's exactly why I don't restrict him with specifics, but was very careful with my own examples, trying to find same-arch, same-process chips in the first place.

>By the way, I have to ask: if out-of-order is so great and power efficient, why are GPUs in-order?
>
>(Yes, that question is mostly rhetorical. However, if I took everything you have
>said in this thread with face value, I would really wonder.)

That's a good question, but it begs a reply: if OoOE is such a complete and utter waste of power and die space, why even the lowest end of PowerPC (603, 602) were OoO -- in times when die space was *much more valuable* than now? Why ARM is going OoO with A9? See? :) But don't answer, I would much rather see Jouni answer this if he'll be back with interesting examples.

Turning back to GPUs, if you want to know why, there was a guy on this board (Hans) who can give a very informative answer, and I would be interested to see him post myself. But if you want to hear something from me, then I think the workloads they are mainly bought for are such when benefits from dynamic scheduling of code have been too small to justify OoO design.

No, I didn't reverse-engineer shader code from many different games to find out what things really look like, it's just an easy guess. E.g. game's CPU code is rarely compiled before playing; e.g. length of v/p shaders was historically a known fixed number for different shader models, whereas in the world of general-purpose computing, code is not required to fit in I$. And back to CPUs, codes don't all behave the way HPC stuff does in that compiler could build a schedule for a given in-order machine that would perform as fast as on a dynamic scheduler. And chips come and go, so what if your binary that ran at close to 100% utilization on an old machine starts stalling every iteration, simply b/c latency of a single insn in the loop went north? Okayish if you have the source and compiler which is good enough to use mdf, not quite so if you don't, is it?