64 vs 32 bit

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)?

- 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?

- Does 64 vs 32 bit have any impact on speed (positively or
  negatively)?  Can single floats be unboxed in 64-bit?

Thanks,

Tamas

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com

Re: 64 vs 32 bit

On Mon, Feb 1, 2010 at 12:08 PM, Tamas K Papp <tkpapp <at> gmail.com> 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.

Re: 64 vs 32 bit

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 <at> gmail.com> 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.

Re: 64 vs 32 bit

In article <hk6vtm$qmm$1 <at> ger.gmane.org>, Adam Majewski <adammaj1 <at> o2.pl> 
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

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com

building 1.0.35.2 fails

Hi,

I tried to build the latest SBCL from CVS (1.0.35.2), but it failed--I
pasted the output to http://paste.lisp.org/display/94246.

1.0.35 builds just fine.  I am using x86_64 GNU/Linux, happy to provide 
more detailed output/info if needed.

Tamas

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com

Re: 64 vs 32 bit

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

> In article <hk6vtm$qmm$1 <at> ger.gmane.org>, Adam Majewski <adammaj1 <at> o2.pl>
> 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

dumping and mmap'ing array

Hi,

I am trying to mmap an array of double-floats.  In particular, my
ideal workflow would be the following:

1. create a 2d array, eg with

(make-array '(10000 100000) :element-type 'double-float)

and fill that array with elements.

2. Dump the array into a file.

3. Load it using mmap, so that it ends up as a Lisp object, and
analyze the contents.

I think I pieced together something that does 3. by slightly modifying
code from a blog post of Juho Snellman:

(defun mmap-lisp-object (map-file)
  "Return a lisp object, corresponding to data dumped into a file."
  (with-open-file (file map-file)
    (let* ((sap (sb-posix:mmap nil
                               (file-length file)
                               sb-posix:prot-read
                               sb-posix:map-private
                               (sb-impl::fd-stream-fd file)
                               0))
           (addr (logior (sb-sys:sap-int sap)
                         sb-vm:other-pointer-lowtag)))

Re: 64 vs 32 bit

> 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

"--script" switch caveats?

Sorry for sending this to sbcl-devel initially:

It seems the Google AI Challenge will be using SBCL for Common Lisp
submissions. Given the way they run the submissions on the server side
I've opted to go with the "--script" commandline switch for loading
the bot.

Are there any caveats, especially speed-wise? I can't really imagine it,
since AFAIK I know the final code will be the same as if it was loaded
and compiled by ASDF, but I just want to be sure.

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com

iterate form evaluates but does not load into sbcl fasl

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com

_______________________________________________
Sbcl-help mailing list
Sbcl-help <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help