Subject: Re: Difference between EQ and EQL
From: rpw3@rpw3.org (Rob Warnock)
Date: Thu, 17 Jan 2008 22:56:00 -0600
Newsgroups: comp.lang.lisp
Message-ID: <z6ydnf7h2Ob9rA3anZ2dnUVZ_gKdnZ2d@speakeasy.net>
Kent M Pitman  <pitman@nhplace.com> wrote:
+---------------
| rpw3@rpw3.org (Rob Warnock) writes:
| > p.s. In 32-bit CMUCL, MOST-POSITIVE-FIXNUM is 536870911, which isn't
| > normally a issue since by default CMUCL has a limit of 512 MiB on
| > dynamic space anyway. But you can run it in such a way that it *does*
| > become an limit:
| >     $ cmucl -dynamic-space-size 1500
| >     ...[chatter]...
| >     cmu> (defvar *monster* (make-array 536870910
| > 				       :element-type '(unsigned-byte 8)))
| 
| I'm not sure I got the joke here, and don't have a lot of time to
| spend on it just this moment, so maybe you can post an explanation for
| the sake of both me and others who might be too shy to ask.
+---------------

Not a "joke" per se [unless you consider picking the name *MONSTER*
for a really *big* array as a joke -- it wasn't intended as such],
just a small demonstration that if you increase the heap size limit
on CMUCL you *don't* necessarily get to define arrays that big.

+---------------
| I do know, and we knew going in, that there's an issue that with 
| small-byte-size arrays where the granularity was such that on various
| kinds of architectures, the likelihood would be that you could easily
| make too many "slots" to index.  That was kind of a no-win the way we
| specified everything ... If you can find any threshold value n such that
| (aref x n) for x being word-sized elements and n being just below the
| max value, then (aref x0 n) for x being something with twice as many 
| elements because they're half as big is sure to lose... Maybe that's what
| you were illustrating here...
+---------------

Exactly. They went to a lot of trouble to allow "-dynamic-space-size"
*much* bigger than the default 512 MiB but the fixnum size[1] still
doesn't let you have byte arrays bigger than 512 MiB. Some people might
consider this to be a defect or at least an undesirable limitation.


-Rob

[1] Determined by the CMUCL pointer-tagging Lisp object representation,
    which uses the low 3 bits but assigns two code points to fixnums,
    which means that fixnums end up being signed 30-bit integers, or
    29 bits for positive array indices. Some other Lisp implementations
    that use pointer-tagging [e.g., MzScheme, for one] have chosen to
    allocate fully *half* of the tag codepoints to fixnums, which for
    a 32-bit Lisp object results in signed 31-bit fixnums or 30 bits
    for positive array indices, or a max byte array size of 1 GiB.

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607