Path: utzoo!attcan!uunet!yale!lisper-bjorn
From: lisper-bjorn@CS.YALE.EDU (Bjorn Lisper)
Newsgroups: comp.arch
Subject: Re: Cray & Amdahl Virtual memory debate
Message-ID: <34254@yale-celray.yale.UUCP>
Date: 26 Jul 88 04:02:30 GMT
References: <4232@cbmvax.UUCP> <76700035@p.cs.uiuc.edu> <5342@june.cs.washington.edu> <537@ns.UUCP> <1534@laidbak.UUCP> <1535@laidbak.UUCP>
Sender: root@yale.UUCP
Reply-To: lisper-bjorn@CS.YALE.EDU (Bjorn Lisper)
Organization: Yale University Computer Science Dept, New Haven CT  06520-2158
Lines: 25

In article <1535@laidbak.UUCP> lm@laidbak.UUCP (Larry McVoy) writes:
>Another thing occurs to me: Brian U of Cray said that their reason for no VM
>is speed.   Someone else pointed out that there is a big difference
>between a development shop (i.e., lots of small processes) and an
>installation (i.e., one large Fortran process).  My take on this is that
>VM may be a lose for the Fortran codes of the world but it is almost 
>certainly a win for everyone else.  In other words, Cray is locking 
>theirselves into the big iron Fortran club (and out of other places?).

"No VM" is not a win for Fortran per se, it is a win for a type of
applications that usually are written in Fortran, namely big
number-crunching scientific-code type applications. The dependence
structures of the algorithms implemented by such codes are usually quite
static and thus possible to detect either at compile-time by a very smart
compiler or *before* compile-time by a smart programmer. When the dependence
structure is known the memory handling can be laid out and optimized for the
particular program. This can be done by the aforementioned very smart
compiler or by the smart programmer provided that he is using a programming
language that allows him full control over the memory handling, for instance
Fortran.

Cray is not locking themselves into the big iron Fortran club. They are
locking themselves into the big iron scientific computing club.

Bjorn Lisper