in Toronto this month: International Symposium on Code Generation and Optimization

[Lennart Sorensen]

On Tue, Apr 06, 2010 at 03:48:05PM -0400, D. Hugh Redelmeier wrote:
> Optimizing compilers can do surprising things.  VLIW compilation
> techniques were not completely new when the Itanium project was
> started.  In fact, a number of the folks at Intel/HP were refugees
> from other projects like Multiflow and Cydrome.  I first heard of VLIW
> technology from a headhunter (for Multiflow) about 25 years ago.

They weren't new, but on the other hand I don't get the impression they
have gotten any further now than they had then.  It very much looks like
a dead end leading no where.  The itanium to me was a gamble on a
technology that was unknown and uncertain.  All it really seems to have
done is kill the alpha (not that DEC wasn't doing a good job at that
themselves), kill HPPA (not sure anyone cares), kill high end MIPS
(that was sad, although embedded use of MIPS is really taking off,
and the chinese are making a 64bit very impressive looking MIPS, so
maybe MIPS will come back from the dead after all), probably hurt sparc
(not sure Sun wasn't doing that themselves to some extent.  When was the
last time a new sparc design was announced and actually got delivered?).
Powercpc seems to be the only highend cpu to have survived other than x86.
If any architecture was deserving of death, it was x86.  Certainly not
the alpha (although I still admit that's probably mostly DEC's fault).

> I've worked on optimizing compilers but I'm not up to date on what
> they can do now.  I do know that results on benchmarks are not that
> indicative of real-world performance.

Certainly there are programs that can optimize well for the VLIW machines.
It just seems most programs can't.  I think I can see why IBM is going for
more cores and more threads per core to take advantage of more execution
units rather than considering anything VLIW.  Not all powerpc's have been
out of order execution though, so even IBM is hoping for compilers to
schedule instructions in a good order without pipeline stalls happening
too much, but they use multithreaded cores to try and fill those pipeline
stalls with other code instead of assuming the compiler will be able to
fill them with instructions from the same code.

> The really tough stuff (i.e. what I don't understand) is how to deal
> usefully with the memory hierarchy.  Especially without programmer
> assistance.
> 
> I recently read a paper about the evolution of the BLAS library and
> successors (Linear algebra kernels) to exploit high-performance system
> architecture changes over the last 30 years.  Wow.  And that is from
> the programmer's standpoint, not the compiler's.  For a well-suited
> problem domain.

Well I was under the impression BLAS had cpu specific optimizations in
many cases (including assembly code for some parts of the code).  It is
certainly very impressive work.

> Multiflow did produce machines that were effective crunchers for a
> point in time.  They were overwhelmed by the attack of the killer
> micros.
> 
> (I don't think that the P4 miss-step was caused by the Itanium.  One
> significant bit of evidence: x86 always got new semiconductor
> fabrication processes well before Itanium (as far as I remember).
> Concern for the Itanium did appear to cause Intel to hold back on
> 64-bit extensions to x86.)

No the itanium certainly is not to blame for the P4.  The P4 I think
can mainly be blamed on marketing.  Intel was highly into selling
clock speed at the time (while AMD and others were starting to push
instructions/clock instead).  They thought they would be able to scale
it to 10GHz, and I suppose if they had, it may have performed sufficiently
well.  Certainly for those clock speeds the long pipeline was a benefit.
For stream processing (like video decoding), the P4 pipeline is quite
good.  Unfortunately it is awful at anything that isn't predictable
(like video encoding, compression in general, etc).

And to keep things on topic, you can run Linux on all of those
architectures mentioned.  Debian supports them all. :)

-- 
Len Sorensen
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists