[Info-vax] RealWorldTech on Poulson

[John Wallace]

On Jul 3, 5:34 pm, Johnny Billquist <b... at softjar.se> wrote:
> On 2011-07-03 18:21, John Wallace wrote:
>
>
>
> > On Jul 3, 3:45 pm, 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.
>
> > "If you gave the 8086 as big a cache as IA64 gets, how much better
> > would
> > the 8086 be compared to IA64 ? "
>
> > A very very fair question, to which we probably won't be told the
> > answer. But IA64 chips are basically a big cache with a weird
> > processor tacked on.
>
> > I'll perhaps have more to say on this subject on a bit, in particular
> > wrt the accuracy and relevance of "x86 microprocessors rely on snoop-
> > based cache coherency;<snip>  In contrast, Tukwila and Poulson have a
> > directory-based coherency protocol that scales much better ...
> > <snip>  ... For a 4 or 16 socket system, the bandwidth savings are
> > huge."
>
> Let's make one thing clear here. The cache coherency strategy design is
> not inherent to the architecture. x86 can use a directory based cache
> coherency just as good as an Itanium. There is no actual performance
> advantage in Itanium itself in this.
> It's just a question of current implementation.
>
> Yes, compiler advances dreamt of by the Itanium team never materialized,
> and honestly it was a desperate dream to start with. Alpha made the
> right choice, but was killed for political reasons.
> At this point, the x86 is a better platform to develop than Itanium,
> which made several bad design choices. It's like the Sparc, who decided
> to have a branch delay slot defined by the architecture. That has hurt
> them ever since.
> Bad processor designs are very hard to recover from. And Itanium seem to
> have collected a lot of those. No clever cache snooping hardware is
> going to change that.
>
>         Johnny
>
> --
> Johnny Billquist                  || "I'm on a bus
>                                    ||  on a psychedelic trip
> email: b... at softjar.se             ||  Reading murder books
> pdp is alive!                     ||  tryin' to stay hip" - B. Idol

"The cache coherency strategy design is not inherent to the
architecture."

Q1) Are you sure about that?
Q2) Does it matter?

A1: I agree that at first glance the cache coherency is not inherent
to the architecture. Then again, why does Alpha have "memory barrier"
instructions rather than a chip<->memory system design which enforces
consistency 100% of the time? And it's not just Alpha. I think the
theory was that it helps design faster systems.

A2: Maybe this "cache efficiency" thing matters, but even the RWT
article admits that in the one to four socket market, it doesn't
matter enough to make AMD64 a bad choice. Given that x86 clock rates
have hit their limit for now (forever?), the market is forced to
accept multicore (or what us oldtimers used to call SMP) as the way
forward. Four sockets gets you 32 Xeon cores (not quite as many
Opterons yet). What kind of workload really needs 32 cores? More
importantly, what kind of operating environment/OS can usefully use 32
cores? Well I guess server consolidation (which seems to be called
virtualisation these days) might, but other than that?

Virtualisation is of course a return to the "shared nothing" approach
to distributed systems, except that today's distributed systems are
often all in the same box, because the OS or the organisation often
isn't capable of having more than one application suite in the same OS
instance, and certainly isn't capable of doing it securely. This is
apparently considered to be progress.

Give these young'uns and PHBs a few years and they might eventually
realise that there is value in actively sharing resources and data,
rather than applying band-aids such as "de-duplicating" filesystem
blocks once it's too late. Maybe someone might invent a distributed
file system with a distributed lock manager so today's indepedent
virtual machines with independent filesystems can tomorrow
interoperate and share resources at a fine level of granularity, and
then maybe in a few years we'll be back to where we were thirty or so
years ago when VMS invented clustering. Maybe.


"Bad processor designs are very hard to recover from. And Itanium seem
to
have collected a lot of those. No clever cache snooping hardware is
going to change that."

I don't know if IA64 is bad. It's just irrelevant. It's VMS that makes
boxes with IA64 interesting. Or NSK. Or maybe even HP-UX.  But VLIW
itself is neither here nor there. Nobody cares about VLIW.

My 2p anyway.