On May 23, 8:02 pm, Ari Johnson <·········@gmail.com> wrote:
> Rainer Joswig <······@lisp.de> writes:
> > Other benefits are:
>
> > * less consing for a lot of applications
>
> It's worth nothing that this is related to faster integer performance,
> since SBCL on x86-64 gives:
>
> * (describe 'most-positive-fixnum)
>
> MOST-POSITIVE-FIXNUM is an external symbol in #<PACKAGE "COMMON-LISP">.
> It is a constant; its value is 1152921504606846975.
> Constant documentation:
> the fixnum closest in value to positive infinity
>
> Less consing for bignums comes with it.
>
> > * the x86 architecture has advantages in 64bit mode.
> > Especially it has more registers. The 32bit mode
> > is a bit 'crippled' when it comes to registers.
>
> The actual numbers are 8 general-purpose registers on x86 and 16 on
> x86-64.
I'm running lisps on 64 bit machines. I'm running OpenMCL on a Mac Pro
(quad) and SBCL on a 64 bit Athlon running Linux. Both work very well.
Both can work on the other machine too.
One reason I was keen to get a 64 bit machine for doing lisp stuff is
because of the (very) large address space. It means you can work with
very large amounts of data without having to worry about reading it
from and writing it to a disk file all the time. This means that some
things can be much, much faster. It can make programming much simpler
too. Of course, if you're working data set is greater than your
available physical RAM the data will be swapped to disk as required by
the operating system, but that doesn't require expensive serialisation
or deserialisation of your data, and is handled efficiently and
transparently for you. OpenMCL on my system currently has allocated
512GB of virtual memory! I don't even have that much disk space.
In C you could memory map a large file to make this sort of thing
persistent too. I don't know if you can do that in lisp - just memory
map a file for the whole lisp heap. That would be useful.
I'd guess on a 64 bit machine with a 64 bit lisp that each cons cell
will take up twice the amount of space.
I think it's thanks to the extra registers that there's an OpenMCL
port for x86-64 architectures (OpenMCL runs on 32 bit PPCs, but not 32
bit x86).
-- David
From: Matthias Buelow
Subject: Re: Common Lisp on 64bits, looking for advice
Date:
Message-ID: <5blqfbF2sqmugU1@mid.dfncis.de>
David wrote:
> In C you could memory map a large file to make this sort of thing
> persistent too. I don't know if you can do that in lisp - just memory
> map a file for the whole lisp heap. That would be useful.
This doesn't always work since the OS (Unixoid systems at least) won't
guarantee that you can always map the file at the same address, for
example, MAP_FIXED with mmap() can fail and I wouldn't depend on it
working. What one could do is attempt to directly map the file, and if
it fails, then load & adjust the heap image from file into a newly
allocated heap by conventional methods. If mmap(...MAP_FIXED...) works
most of the time, that might be a useful strategy for heap persistence.
From: Raymond Wiker
Subject: Re: Common Lisp on 64bits, looking for advice
Date:
Message-ID: <m2myzunmov.fsf@RawMBP.local>
Matthias Buelow <···@incubus.de> writes:
> David wrote:
>
>> In C you could memory map a large file to make this sort of thing
>> persistent too. I don't know if you can do that in lisp - just memory
>> map a file for the whole lisp heap. That would be useful.
>
> This doesn't always work since the OS (Unixoid systems at least) won't
> guarantee that you can always map the file at the same address, for
> example, MAP_FIXED with mmap() can fail and I wouldn't depend on it
> working. What one could do is attempt to directly map the file, and if
> it fails, then load & adjust the heap image from file into a newly
> allocated heap by conventional methods. If mmap(...MAP_FIXED...) works
> most of the time, that might be a useful strategy for heap persistence.
SBCL (and CMUCL?) uses MAP_FIXED on "most" architectures to
allocate the heap (among other things).