From windley@iris  Wed Jul 25 14:11:37 1990
Received: by iris.ucdavis.edu (5.57/UCD.EECS.2.0)
        id AA06565; Wed, 25 Jul 90 14:11:37 PDT
Received: from iris.ucdavis.edu by clover.ucdavis.edu (5.59/UCD.EECS.1.11)
        id AA27653; Wed, 25 Jul 90 14:15:28 PDT
Received: by iris.ucdavis.edu (5.57/UCD.EECS.2.0)
        id AA06561; Wed, 25 Jul 90 14:11:28 PDT
Message-Id: <9007252111.AA06561@iris.ucdavis.edu>
To: info-hol@clover.ucdavis.edu
Subject: AKCL and SparcStations
Date: Wed, 25 Jul 90 14:11:25 PDT
From: Phil Windley <windley@iris>


We have recently found that running HOL using AKCL on a Sparcstation
gets to be a real pain when the size of the core image gets above 16M
(the system thrashes and you get about 10% of the total system).  We
thought that we would just buy mnore memory (since we had 16M in the
machine) and the problem would go away.

I moved from AKCL to Sun CL and that helped.  The thrashing is much
less.  I suspect that SCL does garbage collecting differently than
AKCL since this is usually when the thrashing occured.

I just found out on News, however, that the problem is Sun's memory
management (I've always thought it was brain dead anyway).  I'm
forwarding those articles for your information.


From: lakin@csli.Stanford.EDU (Fred Lakin)
Newsgroups: comp.lang.lisp
Subject: effects of rumored 16 meg virtual memory threshhold on Sparc lisps
Date: 24 Jul 90 17:26:28 GMT
Organization: Center for the Study of Language and Information, Stanford U.

I'm curious as to responses from users,vendors, proponents and lisp
others to this depressing note on sun-spots recently:

  Date:    9 Jul 90 00:09:14 GMT
  >From:    gordoni@chook.ua.oz.au (Gordon Irlam)
  Subject: Sun-4 MMU Performance

           A Guide to Sun-4 Virtual Memory Performance
           ===========================================

                 Gordon Irlam, Adelaide University.
           (gordoni@cs.ua.oz.au or gordoni@chook.ua.oz.au)

  Throughput on a Sparcstation drops substantially once the amount of active
  virtual memory exceeds 16M, and by the time it reaches 25M the machine can
  be running up to 10 times slower than normal.  This is the conclusion I
  reach from running a simplistic test program on an otherwise idle
  Sparcstation.

  .....

  Applications that have a large virtual address space and whose working set
  is spread out in a sparse manner are problematic for the Sun-4 memory
  management architecture, and the only alternatives may be to upgrade to a
  more expensive model, or switch to a different make of computer.  Large
  numerical applications, certain LISP PROGRAMS, and large database
  applications ARE THE MOST LIKELY CANDIDATES.


posting as one who bought a SS just for the purpose of
running lisp,

tnx, f
From: cutting@parc.xerox.com (Doug Cutting)
Newsgroups: comp.lang.lisp
Subject: Re: effects of rumored 16 meg virtual memory threshhold on Sparc lisps
Date: 25 Jul 90 00:22:14 GMT
Organization: Xerox PARC, Palo Alto, CA
In-reply-to: lakin@csli.Stanford.EDU's message of 24 Jul 90 17:26:28 GMT

In article <14613@csli.Stanford.EDU> lakin@csli.Stanford.EDU writes:

   I'm curious as to responses from users,vendors, proponents and lisp
   others to this depressing note on sun-spots recently:

     Date:    9 Jul 90 00:09:14 GMT
     From:    gordoni@chook.ua.oz.au (Gordon Irlam)
     Subject: Sun-4 MMU Performance

     Throughput on a Sparcstation drops substantially once the amount of active
     virtual memory exceeds 16M, and by the time it reaches 25M the machine can
     be running up to 10 times slower than normal.  This is the conclusion I
     reach from running a simplistic test program on an otherwise idle
     Sparcstation.

We two have been bitten by this, but have been informed that Sun will
have a patch for this out quite soon (in a few weeks, according to our
unofficial source).  For ~25Mb Lisp jobs I've experienced a slowdown
closer to 2x, but performance will vary with locality of reference.

        Doug

