Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!emory!hubcap!rbe
From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Newsgroups: comp.parallel
Subject: Re: How much are you willing sacrifice.
Message-ID: <13038@hubcap.clemson.edu>
Date: 8 Feb 91 21:18:46 GMT
References: <12935@hubcap.clemson.edu> <12971@hubcap.clemson.edu>
Sender: fpst@hubcap.clemson.edu
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: I P Sharp Associates, Toronto
Lines: 40
Approved: parallel@hubcap.clemson.edu

Even in the supercomputer biz, there is much to be said for putting
rapid development and maintainability ahead of raw performance for many
applications. 

Some of my colleagues in the where-do-I-drill biz use APL as a modelling
tool for seismic and signal processing. APL offers significant aid in  
understanding algorithms, and has more inherent parallelism than you can
shake a stick at.

They would get a peachy APL model of something, and then decide to run it

against a small real dataset, say around 13 giganumbers.

Swell. Let's wait 6 months until a Cray Fortran guru becomes available,
and until we have a week or so explain what this APL stuff does, and how
that would work in Fortran. THEN, we can run the model on the real data
on the Cray. 

We took a different approach -- we wrote a very quick and dirty APL to C
compiler, which, in spite of the crummy quality of code it produced for the Cray
(This was PCC - the new one is reputed to be lots better),
ran only a few times slower than the best Fortran code they had produced
in the shop.
Furthermore, they could run the models the same day, rather than 6 months
later. 

Now, do you think they cared about a factor of two delay, compared to a
6 month delay?

Also, maintainability issues come back to haunt when you want to
enhance code -- really tweaked code is HARD to enhance unless you 
take as much care in keeping it maintainable as you would if that
was your primary goal. It might also reduce portability -- runs fine
on the Cray, sucks on the Connection Machine.

Apologies for the length of this sermon/tirade.

Bob Bernecky
Snake Island Research Inc.