Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!unmvax!gatech!hubcap!mccalpin
From: mccalpin@loligo.fsu.edu (John McCalpin)
Newsgroups: comp.parallel
Subject: Re: Capabilities of VAST
Message-ID: <3840@hubcap.UUCP>
Date: 12 Dec 88 13:18:33 GMT
Sender: fpst@hubcap.UUCP
Lines: 49
Approved: parallel@hubcap.clemson.edu


In article <3826@hubcap.UUCP> fouts@lemming. (Marty Fouts) writes:
>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.

I have to agree with the first and last statements.

>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.

I think you are getting a little anthropomorphic here.  VAST doesn't 
_ignore_ anything.  It pays equal attention to all code - even code 
that contributes nothing to the total execution time.  Whether it
can _do_ anything with the code may be another story.  
As for the dense matrix inverter, running LINPACK through VAST gives
me code that runs at better than 80% of theoretical peak speed on the
205 and ETA-10.

>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.

If the loops are accessing variables in a non-local manner, then
the problem is with the programmer, not VAST.
The ETA-10 system software is not really ready for large ( >3.5 MWords)
memory jobs yet.  We get great results in monitor mode (no O/S),
but under EOS or UNIX, paging is dreadfully slow.

>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.

I don't know what you mean by this.  "Well prepared" for what?
Perhaps a Cray?

John D. McCalpin
mccalpin@masig1.ocean.fsu.edu
mccalpin@nu.cs.fsu.edu
mccalpin@fsu	(BITNET or MFENET)