Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!vaxine!wjh12!genrad!decvax!mcnc!unc!ulysses!harpo!ihnp4!zehntel!hplabs!sri-unix!pereira
From: pereira@sri-unix.UUCP
Newsgroups: net.lang.prolog
Subject: Re: Why I think partitions are faster than tagging.
Message-ID: <448@sri-unix.UUCP>
Date: Mon, 16-Apr-84 01:57:14 EST
Article-I.D.: sri-unix.448
Posted: Mon Apr 16 01:57:14 1984
Date-Received: Wed, 11-Apr-84 01:53:48 EST
References: <4096@edai.UUCP> basser.256
Lines: 16

I think Andrew Taylor missed Richard O'Keefe's point.  Richard was
talking of term representations where a variable cell occupies a single
32 bit word.  Andrew Taylor's code is clearly for a representation with
64 bits per cell.  For large programs, this factor of 2 in space more
than offsets other considerations. Furthermore, number of memory accesses
is a mojor (THE major?) factor in the efficiency of a Prolog system.
Cells twice as big, twice as many accesses...

Since version 1.4, C-Prolog allows the user to specify the sizes of
data areas in the command line.  The relocation code needed to expand
data areas dynamically is already there, in the function that restores
saved states.  To ensure that the areas being expanded do not walk over
the malloc arena, malloc & friends need to be simulated within
C-Prolog.  Now if only someone out there would take the hint...

-- Fernando Pereira