Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!wuarchive!udel!nigel.ee.udel.edu!mccalpin From: mccalpin@perelandra.cms.udel.edu (John D. McCalpin) Newsgroups: comp.arch Subject: Re: Computers for users not programmers Message-ID: Date: 14 Feb 91 15:58:34 GMT References: <4772@mindlink.UUCP> <1991Feb13.180108.13480@eagle.lerc.nasa.gov> <2933@charon.cwi.nl> <1991Feb14.153747.26911@eagle.lerc.nasa.gov> Sender: usenet@ee.udel.edu Organization: College of Marine Studies, U. Del. Lines: 70 Nntp-Posting-Host: perelandra.cms.udel.edu In-reply-to: xxremak@csduts1.lerc.nasa.gov's message of 14 Feb 91 15:37:47 GMT On 14 Feb 91 15:37:47 GMT,xxremak@csduts1.lerc.nasa.gov (David Remaklus) said: David> Now an architecture question. It seems kind of silly to run David> certain utilities on a CRAY. Even though it can execute a David> compile or grep or edit or etc. very fast, the vector unit sits David> idle for the time the processor spends performing these David> functions. [....] David> Is this a necessary evil in order to get effective use of a David> CRAY or wouldn't offloading this work to more 'appropriate' David> (the definition is left to the reader) platforms within that David> ellusive seamless environment be better? In the past when I have talked to supercomputer vendors about this issue, I have gotten the following three responses. The most important of the "other utilities" in terms of cpu time used is the Fortran compiler, so that is what these answers address: (1) If the supercomputer vendor wanted to move the compiler off of the machine to a "more appropriate" machine, then who is going to decide which one? There are many possibilities: -- a scalar front-end mainframe? -- the users workstation? -- a new, object-code compatible version of the super? There are serious problems with all of these approaches: -- the front-end scalar mainframe may already be busy and will likely not have the user-friendly O/S that the users want; -- the user's workstations come in a bewildering variety of cpu types, O/S revision levels, etc; -- who is going to pay for the development of a slower, cheaper, object-code compatible front-end? Will anyone actually purchase it? (2) The compilers on the supercomputers often use very expensive algorithms in their optimization stages, simply because the supercomputer has the horsepower to do it. Trying to compile a large package on a 1 MIPS workstation (which was what I had at the time) could take 30 minutes instead of 30 seconds. (3) At least on the Cyber 205, I was told (by Neil Lincoln) that the compiler actually made very heavy use of the vector unit. I think I remember Neil telling me that he wrote a paper on the topic of vectorized code optimization in the late 70's or early 80's.... Notice that a number of things have changed in the 4-5 years since I had these conversations: (1) With the overwhelming availability of UNIX in the marketplace, the production of a portable cross-compiler is *much* easier now than it was 5 years ago. For example, with the Cray change from the old CFT compilers (which I believe were written in assembly language) to the new CFT77 compiler (which I believe is written in an HLL --- Pascal maybe?) the porting should be very easy. (2) Instead of a 1 MIPS workstation on my desk, I now have two machines, with integer SPECmarks of 12 and 14, respectively, so the hypothetical 30 minute compile jobs might only be 3 minutes -- a far more attractive number. Other things are still far from the happy paradise of the "seamless environment", especially O/S support for process migration and answers to very difficult questions about how to decide where to run things in a heterogeneous environment.... -- John D. McCalpin mccalpin@perelandra.cms.udel.edu Assistant Professor mccalpin@brahms.udel.edu College of Marine Studies, U. Del. J.MCCALPIN/OMNET