Linus Torvalds (torvalds.delete@this.linux-foundation.org) on July 21, 2020 9:13 am wrote:
> Heikki Kultala (heikk.i.kultala.a.delete@this.gmail.com) on July 21, 2020 3:38 am wrote:
> >
> > But there might still be something good left in the main idea of EPIC
>
> No.
>
> The whole damn architecture was entirely based off the basic incorrect premise that OoO is expensive.
>
> You can make any excuses you like for it, but that's what it boils down to. Static instruction scheduling on a
> micro-level, because the designers thought that OoO was not a long-term viable model even on a small scale.
>
> And that's so fundamentally wrong as to be ludicrous.
>
> Yes, yes, you'll find Intel apologists that claim that EPIC would make sense even with OoO. No. It would not.
> The whole idea with bundles and all the complexity was entirely about the notion that compilers could do all
> that small-scale instruction scheduling statically, so that the hardware wouldn't need to worry about it.
>
> So the whole architecture design pretty much requires that you don't do even the least trivial OoO, because
> even a small instruction scheduling window would have done a better job than what you can do statically (because
> of dynamic behavior wrt any control flow what-so-ever, even unconditional branches like function calls).
>
> In other words: static instruction scheduling is a monumentally bad idea. It's stupid beyond
> words, unless you're doing the tiniest of microcontrollers or DSP's. Doing it for a processor
> design that was supposed to take over the server world? Unbelievably stupid.
>
> So EPIC was very much "VLIW with SW speculation extensions and extra grouping information" from a
> design standpoint, but to actually make it work well, you'd have to just give up on that concept.
>
> IOW, I think Intel could possibly have saved Itanium had they been willing to admit this,
> and just treated Itanium as a strange RISC chip with an odd instruction grouping encoding,
> and make an aggressively OoO implementation. It would still have been a bad architecture design,
> but that's nothing new: Intel made x86 work just fine despite all its problems.
>
> I don't think the odd encoding would have been fatal. It's still a lot easier to parse than
> x86 ever was. The crazy register rotation/stack is nasty, but I think you could have mostly
> ignored it and tracked the rotation in the front end and handled it in the rename logic. Intel
> does more complex things with the x86 stack engine. Again, stupid design, but "solvable".
>
> But if you can admit to yourself that OoO is just a good idea, then pretty much all of the things Itanium did
> were simply wrongheaded and stupid. They weren't necessarily fatal, but they sure weren't great ideas.
>
> What was fatal was not recognizing that OoO is a requirement. If you cannot admit to yourself that
> OoO is what you should do, then the problem is squarely in your end, and I don't know what to say.
>
> Linus

Now, please read the post you are replying to.

I was not talking about ITANIUM having something good in it, but EPIC (ie marking some instructions as independent of each others, without scheduling them) having some good in it.

Itanium is NOT synonym for EPIC even though Itanium is the only commonly-known EPIC-style architecture.

I know that OoOE is vital.

I was thinking about that could EPIC(as in general idea of marking some instructions as indepedent of each other, not itanium ISA) in any way help to make a better OoOE processor.


So you are beating a dead horse in this rant against itanium. Everybody already knows how crap Itanium is.