Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!unmvax!gatech!hubcap!fouts
From: fouts@lemming. (Marty Fouts)
Newsgroups: comp.parallel
Subject: Re: Capabilities of VAST
Message-ID: <3826@hubcap.UUCP>
Date: 9 Dec 88 20:58:09 GMT
Sender: fpst@hubcap.UUCP
Lines: 30
Approved: parallel@hubcap.clemson.edu

Although Vast can do very well with some codes, it can do very poorly
with others.  On the whole, I think using vast can be pretty much a
wash.  Your milage most certainly will vary.

My counter example is a dense matrix inversion program we use as part
of a benchmark suite.  I fed the original to vast, which promptly
ignored the inversion subroutine and concentrated on "optimizing" the
support subroutines by adding code.  The resulting program took some
percent longer to run than the original.

Also, on a certain Navier-Stokes solver, Vast busily inserted
scatter/gather into various loops to cause large vectors to be made
available, which is A Good Thing on the ETA10.  Unfortunately, the
scatters and gathers pretty much trashed any chance of working set
locality which is A Bat Thing on the ETA10.  Adding directives to
prevent the scatter/gather overcame Vast's problem, as did adding
directives in the dense matrix inverter.  However, in both cases,
nontrivial amounts of expert human intervention were required.

For some user communities Vast can be a good win, but if your
community contains a lot of vectorization expertise and the codes were
already well prepared, Vast can be a disaster.

Marty
--
+-+-+-+     I don't know who I am, why should you?     +-+-+-+
   |        fouts@lemming.nas.nasa.gov                    |
   |        ...!ames!orville!fouts                        |
   |        Never attribute to malice what can be         |
+-+-+-+     explained by incompetence.                 +-+-+-+