Return-Path: <John.Harrison-request@cl.cam.ac.uk>
Delivery-Date: 
Received: from leopard.cs.byu.edu (no rfc931) by swan.cl.cam.ac.uk 
          with SMTP (PP-6.5) outside ac.uk; Wed, 2 Nov 1994 12:53:11 +0000
Received: by leopard.cs.byu.edu (1.38.193.4/16.2) id AA16175;
          Wed, 2 Nov 1994 05:50:41 -0700
Sender: info-hol-request@lal.cs.byu.edu
Errors-To: info-hol-request@lal.cs.byu.edu
Precedence: bulk
Received: from oberon.inmos.co.uk by leopard.cs.byu.edu 
          with SMTP (1.38.193.4/16.2) id AA16171;
          Wed, 2 Nov 1994 05:50:38 -0700
Received: from frogland.inmos.co.uk by oberon.inmos.co.uk;
          Wed, 2 Nov 1994 12:42:30 GMT
From: David Shepherd <des@inmos.co.uk>
Message-Id: <8285.9411021237@frogland.inmos.co.uk>
Subject: Re: hardware configuration of your PC for HOL90
To: reetz@ira.uka.de (reetz)
Date: Wed, 2 Nov 1994 12:37:24 +0000 (GMT)
Cc: es774@eng.warwick.ac.uk, info-hol@leopard.cs.byu.edu
In-Reply-To: <"i80fs2.ira.944:02.11.94.10.45.31"@ira.uka.de> from "reetz" at Nov 2, 94 11:45:29 am
X-Mailer: ELM [version 2.4 PL20]
Content-Type: text
Content-Length: 2596

reetz has said:
> 
> Karim writes:
> 
> >It would be interesting to know the hardware configuration of your PC. What
> >Megs of RAM it has? Is it a 486 or pentium machine.
> 
> In my experience, a 486/33Mhz/ISA-Board, 20MB main memory, 64MB swap, Linux
> kernel 1.0.8, is definitely NOT fun. As soon as swap space is needed,
> performance is just crashing down. IMHO you need enough memory to pretend
> swapping.
> 
> Ralf.

getting a bit esoteric for the HOL list ... but Iseem to recall that
the person who did the OS/2 port of SML was shown a way of making
swapping less pronounced by someone involved with a MACH port.

Looking at his comments basically after garbage collection then the OS
(in this case OS/2) is asked first to throw those pages away and then
to reclaim them - i.e. any previous, now redundant, data in them is
lost and when accessed fresh pages will be swapped in.


Here's his comments

------------------------------------------------------------------------
Garbage flushing
----------------

On low-memory machines, quite a lot of time is spent swapping dead heap objects
in & out of RAM after g.c. To minimize this swapping overhead, Greg Morrisett
suggested that a pager-trick was adopted from the Mach port, to avoid swapping
these 'garbage' areas (collected-from arenas).

The 'garbage flushing' has been implemented in this release and simply resets
the dirty pages (with garbage contents) left over from g.c. This is controlled
through the new C function 'gflush'. Use it through a declaration like:

   val gflush: int -> int = System.Unsafe.CInterface.c_function "gflush"

The argument to gflush specifies the requested level of flushing:
   0  - No flushing
   1  - Flush after major collections only
   2  - Flush after major & minor collections
Default level is 1. Gflush returns the previous level.

I have tested the garbage flushing on my 8 Mb 386 box, simply reversing huge
integer lists, and this shows a 2-3 fold speed increase... :-)
However, if you have plenty Mb's of RAM, if you only work with "small" ML
programs, or just never see any excessive swapping activity, you should
probably turn off garbage flushing (gflush 0), to avoid the flushing overhead
(two OS/2 calls per collection).
------------------------------------------------------------------------

--------------------------------------------------------------------------
david shepherd: des@inmos.co.uk                     tel: 0454-616616 x 638
                inmos ltd, 1000 aztec west, almondsbury, bristol, bs12 4sq
		"I  am  not  a  nut      ---      I  am  a  human  being."
