Return-Path: <John.Harrison-request@cl.cam.ac.uk>
Delivery-Date: 
Received: from ted.cs.uidaho.edu (no rfc931) by swan.cl.cam.ac.uk 
          with SMTP (PP-6.5) outside ac.uk; Wed, 12 May 1993 16:07:43 +0100
Received: by ted.cs.uidaho.edu (16.6/1.34) id AA14321;
          Wed, 12 May 93 07:55:00 -0700
Sender: info-hol-request@ted.cs.uidaho.edu
Errors-To: info-hol-request@ted.cs.uidaho.edu
Precedence: bulk
Received: from swan.cl.cam.ac.uk by ted.cs.uidaho.edu (16.6/1.34) id AA14316;
          Wed, 12 May 93 07:54:45 -0700
Received: from albatross.cl.cam.ac.uk (user jvt (rfc931)) by swan.cl.cam.ac.uk 
          with SMTP (PP-6.5) to cl; Wed, 12 May 1993 15:54:36 +0100
Received: by albatross.cl.cam.ac.uk (4.1/SMI-3.0DEV3) id AA23276;
          Wed, 12 May 93 15:54:30 BST
Date: Wed, 12 May 93 15:54:30 BST
From: John.Van-Tassel@cl.cam.ac.uk
Message-Id: <9305121454.AA23276@albatross.cl.cam.ac.uk>
To: info-hol@ted.cs.uidaho.edu
Subject: HOL Performance - FYI

Dear HOL users,

The following information may be of interest to the community.

Franz, Inc. (purveyor of Allego CL), has recently been urging users
to build saved images using a new mechanism.  I have done some tests
to determine whether there is any significant win for HOL if one
switched to this new regime.  The results follow below.

I have been able to get HOL built using the Allegro "config" (as
opposed to "dumplisp") in version 4.1 of the lisp.  The HOL image is
2Mb smaller than that done with dumplisp.  Speed-wise, it is much
slower than the AKCL version on the benchmark (all times in seconds):


                                     Run Time     GC Time     Total
   Allegro (w/ dumplisp)              149.0         10.0      159.0
   Allegro (w/ config)                146.6          8.3      154.9
   AKCL (w/ dumplisp + GC mods*)       51.9          9.2       61.1

      * AKCL space allocation changes as distributed in contrib for
        version 1-615 of the lisp.


All the above tests were perfomed on a SparcServer 10 w/ 96 Mb of real
memory using HOL 2.01.  The "Run Time" number is the raw speed of the
lisp when it is actually doing computation.  This is a statistic that
measures the real speed of the lisp, and it cannot be changed (unless
one is willing to fiddle with explicit code locations - YUK!).  Note
that neither the AKCL or Allegro versions have had any code
re-arrangements applied.  The GC number is the time spent in garbage
collection, and forms no part of the run time number.  The space
allocation modifications mentioned above only affect GC performance.
Run time does not change after they are applied.  There is no
guarantee that these results migrate to other platforms.

Building the HOL image with the Allegro config utility is very
inelegant (although it could be cleaned up a bit), and really only
affects disc utilisation.  The question is, would users like to see a
"config"-based build procedure for Allegro versions of HOL in the next
release of the system?  It is not clear whether Allegro is going to do
away with the current way in which saved images are created.

JVT

------------------------------------------------------------------------------
John Van Tassel			|  Tel: +44-223-334729
Univ. of Cambridge		|  Fax: +44-223-334678
Computer Laboratory		|  
Pembroke Street			|  Email: jvt@cl.cam.ac.uk
Cambridge CB2 3QG		|
England				|

