Steel Bank Common Lisp

On Mon, Feb 1, 2010 at 12:08 PM, Tamas K Papp <tkpapp@...> wrote:
> Hi,
>
> Currently, I am using SBCL on 32-bit Ubuntu (x86).  I ran into a
> specific limitation (fixnum limits my array size), so am wondering
> whether to switch to 64-bit SBCL.  This would require a reinstall,
> which is not a major issue but a minor PITA which would surely take a
> few hours.  Before I undertake this, I have a few questions:
>
> - how big is ARRAY-TOTAL-SIZE-LIMIT on 64-bit SBCL?  Will this allow
>  me to use larger arrays?  Is there another limit (provided that I
>  take enough memory with a --dynamic-space-size)?
ARRAY-TOTAL-SIZE-LIMIT is (- most-positive-fixnum  2) and will indeed
allow using larger arrays.

> - Does 64-bit result in significantly a higher memory consumption?  I
>  understand that fixnums will now take twice the space, but does
>  anything else take up more memory?
Pointers will take double memory as well. I don't have a 64-bit
machine at hand, and I don't remember how much more memory it
consumes, but the core image is almost twice as large.

> - Does 64 vs 32 bit have any impact on speed (positively or
>  negatively)?  Can single floats be unboxed in 64-bit?
>
Yes, single floats are immediate. And 64-bit sbcl uses SSE2 for float
and complex operations.

-- 
With best regards, Stas.

Dnia Mon, 01 Feb 2010 17:36:11 +0300, Stas Boukarev napisał(a):

> On Mon, Feb 1, 2010 at 12:08 PM, Tamas K Papp <tkpapp@...> wrote:
>> Hi,
>>
>> Currently, I am using SBCL on 32-bit Ubuntu (x86).  I ran into a
>> specific limitation (fixnum limits my array size), so am wondering
>> whether to switch to 64-bit SBCL.  This would require a reinstall,
>> which is not a major issue but a minor PITA which would surely take a
>> few hours.  Before I undertake this, I have a few questions:
>>
>> - how big is ARRAY-TOTAL-SIZE-LIMIT on 64-bit SBCL?  Will this allow
>>  me to use larger arrays?  Is there another limit (provided that I
>>  take enough memory with a --dynamic-space-size)?
> ARRAY-TOTAL-SIZE-LIMIT is (- most-positive-fixnum  2) and will indeed
> allow using larger arrays.
> 
>> - Does 64-bit result in significantly a higher memory consumption?  I
>>  understand that fixnums will now take twice the space, but does
>>  anything else take up more memory?
> Pointers will take double memory as well. I don't have a 64-bit machine
> at hand, and I don't remember how much more memory it consumes, but the
> core image is almost twice as large.
> 
>> - Does 64 vs 32 bit have any impact on speed (positively or
>>  negatively)?  Can single floats be unboxed in 64-bit?
>>
> Yes, single floats are immediate. And 64-bit sbcl uses SSE2 for float
> and complex operations.

Hi,


I have SBCL on 64-bit Ubuntu

In my computer :
ARRAY-TOTAL-SIZE-LIMIT
1152921504606846973

I have installed sbcl using :

sudo  apt-get install slime cl-swank sbcl 
echo '(setq inferior-lisp-program "sbcl")' >> ~/.emacs

I'm intresting in using bigger memmory in SBCL.
Should I compile SBCL from sources ?

Regards

Adam

In article <hk6vtm$qmm$1@...>, Adam Majewski <adammaj1@...> 
wrote:
> I have SBCL on 64-bit Ubuntu
> 
> In my computer :
> ARRAY-TOTAL-SIZE-LIMIT
> 1152921504606846973
[...]
> 
> I'm intresting in using bigger memmory in SBCL.
> Should I compile SBCL from sources ?

As far as I know, all x86-64 chips currently available can only handle 
up to 48 bits of address space. You can expect to have a couple more 
years before even getting close to 60 bits of address space. How have 
you determined that you need to use larger arrays than is currently 
supported by SBCL/x86-64, and how do you expect that to work on your 
hardware?

Paul Khuong

Dnia Mon, 01 Feb 2010 13:12:15 -0500, Paul Khuong napisał(a):

> In article <hk6vtm$qmm$1@...>, Adam Majewski <adammaj1@...>
> wrote:
>> I have SBCL on 64-bit Ubuntu
>> 
>> In my computer :
>> ARRAY-TOTAL-SIZE-LIMIT
>> 1152921504606846973
> [...]
>> 
>> I'm intresting in using bigger memmory in SBCL. Should I compile SBCL
>> from sources ?
> 
> As far as I know, all x86-64 chips currently available can only handle
> up to 48 bits of address space.

If I'm not wrong :
"48-bit addressing method increases the address space to: 
144,115,188,075,855,872 bytes (144 Petabytes)"

....



> How have
> you determined that you need to use larger arrays than is currently
> supported by SBCL/x86-64, and how do you expect that to work on your
> hardware?
> 
> Paul Khuong


Of course I do not need so much memory. I have thought about memory 
bigger then I have 
( now I have 2GB )

Sorry for wrong question.
Proper question is:
If I will have more memory in my computer should I do sth to use all my 
new memory with sbcl ?

I had lisp memory erors when working with Maxima :

Maxima encountered a Lisp error.
Error in MSZ-MPLUS [or a callee]: The storage for CONS is exhausted.
Currently, 69458 pages are allocated.
Use ALLOCATE to expand the space.


I have found some info about it :
http://fraktal.republika.pl/doc/maxima%20error%20codes.txt

This is why I think about bigger memory ( but not so big)


Regards

Adam

> Of course I do not need so much memory. I have thought about memory
> bigger then I have
> ( now I have 2GB )
>
> Sorry for wrong question.
> Proper question is:
> If I will have more memory in my computer should I do sth to use all my
> new memory with sbcl ?


I wouldn't worry too much; sbcl seems to claim 8Gb of memory by default,
and to fall over with a surprised expression if it then discovers the hard
way that there isn't that much available.

The option you'll find most useful is the --dynamic-space-size runtime
argument, which lets you tell sbcl how many Mb to reserve. I've found it
very useful to restrict the allocation to 256Mb because:
a) it starts up _much_ faster
b) that's all that's spare on the server that runs my applications
c) that's really all it needs for what I'm doing anyway

In your case, if you need more rather than less, you can easily specify
something like -dynamic-space-size 4096 to tell it to reserve 4Gb, which
ought to be enough for anybody :)

The relevant manual page is http://www.sbcl.org/manual/Runtime-Options.html
- you'll find it useful to read through the runtime and toplevel options
anyway, just to know what's available.

There's a further option of compiling sbcl with a different default
allocation. You'll find a discussion on that subject in this list's recent
archives if you want to go to that extent, but the runtime option will
almost certainly be sufficient - it's also a bit more flexible if you want
to start the same binary with different allocations at different times.


Hoping this helps,
James