Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!labrea!rutgers!cmcl2!yale!mfci!rodman
From: rodman@mfci.UUCP (Paul Rodman)
Newsgroups: comp.arch
Subject: Re: Don't look back
Message-ID: <675@m3.mfci.UUCP>
Date: 27 Feb 89 15:08:35 GMT
References: <13582@winchester.mips.COM> <20667@lll-winken.LLNL.GOV> <7330@pyr.gatech.EDU> <656@m3.mfci.UUCP> <20821@lll-winken.LLNL.GOV> <661@m3.mfci.UUCP> <20862@lll-winken.LLNL.GOV>
Sender: rodman@mfci.UUCP
Reply-To: rodman@mfci.UUCP (Paul Rodman)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 60

In article <20862@lll-winken.LLNL.GOV> brooks@maddog.llnl.gov.UUCP (Eugene Brooks) writes:

>Some time back I posted a challenge to VLIW proponents to compile and run a
>parallel Monte Carlo code of mine and compare the performance to a box full
>of microprocessors.  There were no takers.  This challenge is still open.

A "box" full of microprocessors? 

Look, if you've got some money, call a salesman and benchmark your code.
If you like the results buy the Trace. Don't conclude that just because 
there were no takers that you have "proved" anything. 

Secondly, if somehow you've managed to port your application to a "box" of
micros, congratulations, but most folks don't have the time to do such things.
Most computer users have large programs that couldn't be ported to a "box"
of micros in month of Sundays.

Eventually, *more* use for  multiple-cpu systems will find its way to more
and more to rank-and-file computer users (for something more than
time-sharing peformance.) When that happens you'll still be better off
with a small number of faster machines (VLIWs) than a large number of
slow ones. Unless, of course, you have just the right application.

>
>I would also like to see a detailed justification for the statement that VLIW
>processors will displace vector processors at what they do best.  

Why would I need to prove such a silly thing? Why shouldn't *you* have to 
prove that vector processor can even come close to VLIWs at what *they* do 
best. (A much large set of programs, by the way.) Would you like to write
vector programs, or programs with parallel expressions? The latter is much
easier.

Even if your vector performance is some fraction less than a vector machines
unless the users application is incredibly vectorizable, you'll easily 
win due to non-vector speedups. I'm sure you've read Olaf Ludbeck paper
from Los Alamos, haven't you? What does that paper tell *you*? It tells
me that even if the vector machines at Los Alamos had *infinite* speed 
vector units the speedups are dismal. In a *decade*+ of programming vector
machines, some of the best scientists in the world haven't improved the
percent vectorization. 

>A VLIW
>machine has not yet outrun a vector processor yet on its favorite workload
>and I do not see any technology trend that leads to this conclusion even for
>the long term.
>

That's because you aren't looking. Vector compilers are topped out, in case
you haven't noticed. Vector compilers have been around a long, long time
and have gotten quite good. This is *bad* news for vector compilers , not
good news.

A decent VLIW+compiler has only just popped on the commercial scene, relativly
speaking. Do you think that we are standing still?



    Paul K. Rodman 
    rodman@mfci.uucp