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