Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!rpi!crdgw1!crdos1!davidsen From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) Newsgroups: comp.arch Subject: Re: Computers for users not programmers Message-ID: <3205@crdos1.crd.ge.COM> Date: 15 Feb 91 13:34:20 GMT References: <4772@mindlink.UUCP> <1991Feb13.180108.13480@eagle.lerc.nasa.gov> <2933@charon.cwi.nl> <1991Feb14.153747.26911@eagle.lerc.nasa.gov> Reply-To: davidsen@crdos1.crd.ge.com (bill davidsen) Organization: GE Corp R&D Center, Schenectady NY Lines: 26 In article mccalpin@perelandra.cms.udel.edu (John D. McCalpin) writes: | (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. I'm told that one of the programs which benefited from the Convex vectorizing C compiler was the Convex vectorizing C compiler... optimization should be able to use be parallel and vector technology. | 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.... I would like to see the workstation slide jobs off onto the SC for execution, and given enough bandwidth that's possible. The problem is that the output of these jobs is sometimes very large, and it would have to come back. If you could put the files on the SC and NFS export them, without wasting a lot of CPU on the SC, that might be a solution. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "I'll come home in one of two ways, the big parade or in a body bag. I prefer the former but I'll take the latter" -Sgt Marco Rodrigez