someone (someone.delete@this.somewhere.com) on September 27, 2013 12:24 pm wrote:
> bakaneko (nyan.delete@this.hyan.wan) on September 27, 2013 10:10 am wrote:
[snip]
>> That's besides the point, Intel had data that
>> VLIW sucked. Hard. They may not have been able
>> to pinpoint why, but they had data that showed
>> that VLIW designs don't compete even before
>> Itanium.
>
> Wrong. A simple comparison of the data points of high end processors all
> made in 0.18 um Al interconnect bulk CMOS shows otherwise. (SPEC CPU 2k)
>
> [Power4/1300 - 822/1202 ***SOI/Cu device, perhaps 10% faster than bulk Al 0.18 um impl.***]
> McKinley i2/1000 - 810/1431
> Athlon XP/1733 - 720/613
> Willam. P4/2000 - 681/735
> Alpha ev68b/933 - 579/724 (no official submission, scaled from 0.18 um Cu ev68b 1 GHz result)
>
> Where's the problem?

McKinley was impressive (especially relative to Merced) and comparing for the same process technology would give some insight into performance from Architecture. (The FP results can probably be ignored for an argument about the suitability of VLIW. VLIW is known to be good for classic FP workloads. I would also weakly complain that SPEC CPU 2000 allowed profile-guided optimization for base results; this would give an EPIC ISA an advantage over other ISAs.)

Unfortunately one cannot exclude secondary effects. Presumably McKinley had fewer design resources available than Willamette (or even Athlon XP if one excludes any sharing at Intel between x86 and Itanium?). McKinley was only the second implementation of the ISA (compiler maturity might also have been an issue). McKinley had higher power and chip area budgets than Athlon. McKinley was also targeted at different workloads than Athlon (for SPEC CPU2000 Int, this might give Athlon an advantage). Athlon presumably had some binning advantage (it is not clear if IBM significantly binned POWER4 by not selling parts that could not reach 1GHz).

It also seems that Itanium's design teams have been artificially constrained by the EPIC design philosophy. Not only was an out-of-order design option strongly handicapped (there are comp.arch posts indicating it was required to beat a paper tiger), but I suspect that even the relatively decoupled execution of Poulson was not readily embraced. (While the 10 year delay to Poulson may merely represent a lack of design resources, given the VLIW philosophy behind Itanium, it would not be surprising that even weakly dynamic scheduling would be viewed negatively. The abandoning of a proposed one-bundle-wide implementation might be a similar hint at a bias toward more classic VLIW/EPIC philosophy--dynamic scheduling violates the explicit nature of the parallelism, narrow issue violates the parallel nature.)

The VLIW-ish design of the Itanium ISA also places some constraints on microarchitectural diversity. x86 might be so ugly that microarchitectural cleverness flourished, and RISC might be sufficiently orthogonal to implementation that such cleverness is not impeded (albeit perhaps not encouraged as much as x86 even given equal resources). Itanium has more features that target a particular set of microarchitectures. This means that it can be more effective than RISC for those microarchitectures but also means that it can less effective for other microarchitectures.

(If Itanium had only had to compete against UltraSPARC, a declining Alpha, and a POWER3 follow-on, then the high-end RISC market might have been in greater danger. POWER4 was not just a POWER3 follow-on, so Itanium faced a more challenging market than might have been expected.)

Currently, if one were designing an ISA for the equivalent of the server/workstation market, one would presumably have less emphasis on ILP and more emphasis on the memory system and power efficiency. (One might also have more emphasis on down-scaling to performance targets below those of a traditional server/workstation processor.)