Menu
▾
▴
clisp-devel
|
From: Bruno H. <br...@cl...> - 2005-05-14 13:54:20
|
Hi,
I've committed a patch that allows for 48-bit fixnums on 64-bit platforms.
Noteworthy changes:
- a new integer type 'uintV' that is the smallest integer type that can
accomodate a nonnegative fixnum's value. Either uint32 or uint64.
- posfixnum_to_L is gone. More precisely, it's replaced with posfixnum_to_V,
which returns a n uintV.
- In modules like rawsock or bdb, it is now a BUG to write
unsigned int foo = posfixnum_to_V(check_posfixnum(STACK_0));
because that would cause values between 2^32 and most-positive-fixnum
to be accepted but to be truncated. As a replacement, use
unsigned int foo = I_to_uint(check_uint(STACK_0));
Bruno
|
|
From: Sam S. <sd...@gn...> - 2005-05-17 00:29:57
|
> * Bruno Haible <oe...@py...> [2005-05-14 15:43:20 +0200]: > > I've committed a patch that allows for 48-bit fixnums on 64-bit > platforms. congratulations! this is really great news! please do not forget to update src/NEWS and doc/impbody.xml thanks! -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.mideasttruth.com/> <http://www.palestinefacts.org/> <http://pmw.org.il/> <http://www.jihadwatch.org/> <http://www.iris.org.il> I don't have an attitude problem. You have a perception problem. |
|
From: Bruno H. <br...@cl...> - 2005-05-30 13:15:36
|
Sam wrote: > > I've committed a patch that allows for 48-bit fixnums on 64-bit > > platforms. > > congratulations! > this is really great news! > please do not forget to update src/NEWS and doc/impbody.xml Thanks. Done. Bruno |
|
From: Sam S. <sd...@gn...> - 2005-05-17 01:33:12
|
> * Bruno Haible <oe...@py...> [2005-05-14 15:43:20 +0200]: > > I've committed a patch that allows for 48-bit fixnums on 64-bit > platforms. this did not affect array size limits. why? -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.palestinefacts.org/> <http://www.dhimmi.com/> <http://www.jihadwatch.org/> <http://www.iris.org.il> <http://www.camera.org> WinWord 6.0 UNinstall: Not enough disk space to uninstall WinWord |
|
From: Bruno H. <br...@cl...> - 2005-05-30 13:15:36
|
Sam wrote: > > I've committed a patch that allows for 48-bit fixnums on 64-bit > > platforms. > > this did not affect array size limits. > why? It was not my goal to increase the memory size of every array (by increasing its 'length' field from uintL to uintV). Bruno |
|
From: Sam S. <sd...@gn...> - 2005-06-05 21:21:40
|
> * Bruno Haible <oe...@py...> [2005-05-30 14:50:00 +0200]: > > Sam wrote: >> > I've committed a patch that allows for 48-bit fixnums on 64-bit >> > platforms. >> >> this did not affect array size limits. >> why? > > It was not my goal to increase the memory size of every array (by > increasing its 'length' field from uintL to uintV). an extra 4 bytes is nothing compared to extra functionality. (can you add a "large array" flag?) -- Sam Steingold (http://www.podval.org/~sds) running FC3 GNU/Linux <http://www.dhimmi.com/> <http://pmw.org.il/> <http://www.jihadwatch.org/> <http://www.iris.org.il> <http://www.mideasttruth.com/> <http://www.camera.org> The world will end in 5 minutes. Please log out. |
|
From: Bruno H. <br...@cl...> - 2005-06-06 11:14:35
|
Sam wrote:
> > It was not my goal to increase the memory size of every array (by
> > increasing its 'length' field from uintL to uintV).
>
> an extra 4 bytes is nothing compared to extra functionality.
Please think about it again.
IRIX died because it ate too much memory. The causal chain was this;
- IRIX ate too much memory =>
- users observed slow and sluggish behaviour =>
- users considered alternatives like Solaris =>
- further developments were not worth the development cost, because the
user base was already too small.
> (can you add a "large array" flag?)
Have you already needed an array with 4,000,000,000 elements?
Bruno
|
|
From: Sam S. <sd...@gn...> - 2005-06-06 18:03:03
|
> * Bruno Haible <oe...@py...> [2005-06-06 13:13:23 +0200]: > > Sam wrote: >> > It was not my goal to increase the memory size of every array (by >> > increasing its 'length' field from uintL to uintV). >> >> an extra 2 bytes is nothing compared to extra functionality. > > Please think about it again. > > IRIX died because it ate too much memory. The causal chain was this; > - IRIX ate too much memory => > - users observed slow and sluggish behaviour => > - users considered alternatives like Solaris => > - further developments were not worth the development cost, because the > user base was already too small. and what does adding 2 bytes to each vector have to do with this? Bytes permanently allocated: 66792 Bytes currently in use: 1774088 Bytes available until next GC: 121192 1774088 ; 121192 SIMPLE-STRING 11246 466372 41.470 SIMPLE-VECTOR 4638 245820 53.001 SIMPLE-8BIT-VECTOR 2936 222252 75.699 STRING 292 7016 24.027 SIMPLE-BIT-VECTOR 495 4784 9.665 VECTOR 95 2660 28.000 this will add (* 2 (+ 11246 4638 2936 292 495 95)) 39404 bytes - less than 40k to a 2M image - 2%. clisp is already very frugal on memory. 2 bytes per vector is a cheap price to pay for large arrays. >> (can you add a "large array" flag?) > Have you already needed an array with 4,000,000,000 elements? when I (or someone else) needs it, it will be too late to ask you to modify CLISP (especially given our release rate). when people need it, they need it _NOW_. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.palestinefacts.org/> <http://www.openvotingconsortium.org/> <http://www.mideasttruth.com/> <http://www.iris.org.il> There are no answers, only cross references. |
|
From: Bruno H. <br...@cl...> - 2005-06-06 18:24:18
|
Sam wrote: > and what does adding 2 bytes to each vector have to do with this? It's not 2 bytes, it's 8 bytes: First, when a length field increases from 4 to 8 bytes, it's +4 bytes. Due to alignment reasons (on 64-bit platforms, varobject_alignment is 8), it's either +0 or +8. > this will add > (* 2 (+ 11246 4638 2936 292 495 95)) > 39404 bytes - less than 40k to a 2M image - 2%. No, it will add either 0 or 160k to a 2MB image - 0% or 8%. And 8% more memory means typically 16% slowdown (rule of thumb). Now, when you look at the definitions of VAROBJECT_HEADER and VRECORD_HEADER, you see that on 64-bit platforms there is currently a hole of 4 bytes in the header. So it's really +0% more memory. !! :-) Bruno |
|
From: Sam S. <sd...@gn...> - 2005-06-06 19:34:37
|
> * Bruno Haible <oe...@py...> [2005-06-06 20:23:05 +0200]: > > Now, when you look at the definitions of VAROBJECT_HEADER and > VRECORD_HEADER, you see that on 64-bit platforms there is currently a > hole of 4 bytes in the header. So it's really +0% more memory. !! :-) I cannot navigate through the maze of #ifdefs, but I will take your word that CLISP will soon get huge arrays. :-) -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.iris.org.il> <http://www.memri.org/> <http://www.camera.org> <http://www.dhimmi.com/> <http://www.openvotingconsortium.org/> Save the whales, feed the hungry, free the mallocs. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X