aingalls@sunfun.eta.com (Andrew Ingalls) (12/10/88)
[ On comp.compilers, I had asked for a catalog of capbilites of the
VAST preprocessor. The following was provided. Pacific Sierra
was also kind enough to respond on further development and an
new expert system product. Contact PSR for more info
- Steve
]
Well, I'm at work now and have my Vast manual in front of me so
I can (hopefully) answer some of your questions.
A more complete list of Vast-2's capabilities :
- Vectorization of both DO loops and IF loops
- Vectorization of outer loops
- Sophisticated data dependency analysis to ensure safe translation
of loops
- Examination of EQUIVALENCE statments to detect hidden recursion
- Ability to reorder array references to avoid recursion, where
possible
- Use of program information from outside the loop to aid data
dependency analysis (ambiguous subscript resolution)
- Ability to minimize data-dependant sections of loops so that the
maximum amount of computation is vectorized
- Ability to handle all forward-branching conditional operations,
regardless of nestin of complexity
- Use of program information from outside the loop to determine
whether final values of indices and of scalar temporaries are
required
- Use of program information from outside the loop to determine
whether or not reduction function initializations can be eliminated
- Re-rolling of unrolled loops
- Elimination of common vector subexpressions
- Ability to select the single best dimension on a loop nest
- Ability to collapse loop nests to increase average vector length
- In-line expansion of subroutines and functions
- Tidy feature to control appearance of output (indenting, spacing,
and so forth)
- User directives and switches to control many aspects of the
translation process
Vast will also send the user diagnostics in the form of :
-- Warnings if potential data dependancies or recursion exist
-- Explanations as to why a loop (or loop nest) was not vectorized
-- Messages asking for more user input (in the form of directives)
I would include examples but all the interesting ones contain alot of
instructions and special calls that are specific to our machine and our
compiler (Eta-10, Ftn77) and wouldn't make alot of sense unless you were
familiar with both.
We've seen some really impressive results when using the vectorizer alone
and absolutely amazing speedups (in certain cases) when the directives are
used correctly. I have no affiliation with Pacific Sierra Research Corp.
other than the fact that my company purchases the Vast product from them.
I (and many of our customers) are very happy with the product (even though
we always want more). If you or the 'several others who are interested'
want specific examples, I would be happy to oblige.
Eta is a trademark of ETA Systems, Incorporated.
Vast-2 is a trademark of Pacific-Sierra Research Corporation.
Views and/or opinions expressed herein are the sole reponsibility of the
author and do not (necessarily) reflect the policies/views/opinions of
ETA Systems.
I hope this helps and please, E-mail me if I haven't answered
your questions.
Paul Hinker (sneaking in as Andrew Ingalls)
INET : phinker@aring.ETA.COM
-- Steve,
I hope this gets through this time. The first time I tried it, it bounced
around for awhile and ended up back on our network in someone else's mailbox!
Paul Hinker (still pretending to be Andrew Ingalls)
INET : phinker@aring.eta.com
-- Steve,
This is the third time and hopefully you'll get it.
Paul Hinker (Continuing to impersonate Andy)fouts@lemming. (Marty Fouts) (12/10/88)
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. +-+-+-+
mccalpin@loligo.fsu.edu (John McCalpin) (12/12/88)
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)
fouts@lemming. (Marty Fouts) (12/13/88)
In article <3840@hubcap.UUCP> mccalpin@loligo.fsu.edu (John McCalpin) writes: In article <3826@hubcap.UUCP> fouts@lemming. (Marty Fouts) writes: >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 *problem* is *not* with the programmer, but with the universe the programmer is required to operate in. It is often necessary to write algorithms which need to make two passes at data, one in the row order, and one in the column order. Independent on the language one of these passes will be "non-local". . . This is the case with this solver. >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? An example of "Well prepared" is the code LES (Large Eddy Simulator) developed here at Ames. Originally written for a Cyber 205, it attempts to alleviate its need to pass through an array in both row and column order by doing a transpose between the passes. The transpose helps both the virtual memory systems and the Cray machines, by overcoming know problems in both kinds of machines. There are two seperate versions of the transpose, one which is efficent on a virtual memory system, and one which is efficent on a Cray. Further, loops are designed to compile to long vector lengths, as is required to maximize efficency on an ETA10. To give such a code to Vast is to court disaster, since anything short of hand rewriting the assembly code from inner loops is going to make the program run slower. The point is that the closer the original code comes to being optimal for the machine, the more likely Vast is to do produce a less optimal result. 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. +-+-+-+