[Info-vax] RealWorldTech on Poulson

[Neil Rieck]

On Jul 3, 10:45 am, JF Mezei <jfmezei.spam... at vaxination.ca> wrote:
> Neil Rieck wrote:
> > As I understand the current debacle, EPIC relied on advances in
> > complier technology which never occurred.
>
> How can a compiler predict how a data processing program will execute
> since the compiler doesn't have any idea what data will be processed ?
>
> Compilers can do wonderful things when a program calculates pi to
> infinite  precision since the logic is fixed and the copiler can really
> optimise it. But for situations wherethe flow of the program depends on
> the data being processed (data to which the compiler does not have
> access), then EPIC can't rely on compiler advances.
>
> The Alpha presentations pre-June-25-2001 that showed why IA64 would not
> work are still valid today.
>
> If you gave the 8086 as big a cache as IA64 gets, how much better would
> the 8086 be compared to IA64 ?
>
> At the end of the day, IA64 gets palatable performance due to brute force.
>
> > Personal comment: I think Intel and HP are currently at a critical
> > point where the next few decisions will allow the Itanium program to
> > "take flight and dominate the enterprise  market" or crash.
>
> A rolling stone gathers no moss. Converting IA64 to a normal chip with
> the advanced features found on competing platforms will liekly take a
> couple of iterations during whic the platform will be in a state of
> flux, with customers not too happy with performance unless they have to
> recompile/recertify all their applications.
>
> And while Intel/HP are touting Poulson as the next best thing since
> sliced bread, lets not forget that the 8086 is not be idle and by the
> time Poulson comes out, the 8086 may have even widened the gap between
> itself and IA64.
>
> > As far as HP is concerned, PA-RISC
> > and Alpha are gone so the death of Itanium would hurt them.
>
> The plans set forth by LaCarly may contiue: move enterprise computing to
> commodity hardware. HP will just need to move its OS to the 8086 and
> focus on building a full range of industry standard servers intluding
> big iron.
>
> When you compare the costs of developping IA64 and its compilers, it may
> end up being much cheaper to port HP-UX/NSK and perhaps even VMS to the
> 8086 and use existing compilers for that platform.

I think we are talking past each other so let me speak (type) plainly:
EPIC did not work. If the compiler technology required to make EPIC
work was possible then we would have seen it by now. So whenever you
hear the phrase EPIC think "first-generation RISC without the
possibility of super-scalar features". Intel engineers probably have
been aware if this fact for a while now.

So Intel only has a couple of alternatives:
1) do nothing more than die-shrinks then watch their massive
investment investment fade away (over the years) while SPARC and POWER
enjoy continued architectural improvements while poaching Intel
customers (BTW, Intel employees working on Itanium can kiss their jobs
goodbye)
2) slowly (over the next few years) nudge Itanium away from EPIC to
the direction of RISC (while adding in super scalar features dependent
upon how far they move.)

I'm not sure I agree with your statement "When you compare the costs
of developing IA64 and its compilers" as it stands. I'm going to
assume that Intel has no desire to walk away from their investment in
Itanium and so will do whatever it takes to move this product forward.
That leaves us with compilers: Developing software can be many orders
of magnitude less expensive than developing hardware. The industry has
years (two decades?) of experience developing compiler technology for
Super Scalar RISC. HPQ has lots of working examples of it in GEM/Alpha
code generators.

But this is all arm-chair quarterbacking. Let's see what Intel/HPQ
come up with for 2012.

NSR