Re: 3 questions about arrays

Spiros Bousbouras wrote:
On Fri, 04 Dec 2009 01:10:12 +0100
pjb@xxxxxxxxxxxxxxxxx (Pascal J. Bourguignon) wrote:
Spiros Bousbouras <spibou@xxxxxxxxx> writes:

1. (setq *PRINT-ARRAY* t)
(make-array 1)

Is this undefined behavior ?
No, it is implementation dependant, but not undefined.

The HS page on make-array says "If initial-element is not supplied, the
consequences of later reading an uninitialized element of new-array are
undefined unless either initial-contents is supplied or displaced-to is
non-nil". In order to print the elements of the array doesn't the
implementation need to read them ? If yes then it's undefined behavior.

2. Why the requirement that the dimensions of an array are fixnums ?
Why not? This is not a big restriction, if an implementation wants
bigger arrays, it only has to provide bigger fixnums.

fixnums are supposed to be efficient , that's the criterion for
choosing the size of fixnums not the maximum size of arrays. On the
other hand the maximum size of arrays should be what the operating
system can handle even if it means that part of the array would be in
swap memory.

Nuh-uh.

1) That's already the case in plenty of CL implementations -- unless a lot of people have 60 bits of physical memory they're not telling anyone about. (Even on 32-bit operating systems, a single fixnum-denominated array can already use up at least all of physical memory and quite possibly more, depending on what's in the array.)

2) Now array-size limit depends not on the lisp but on the OS and the disks you have handy and how much someone allocated for /swap and what other programs are running. Good luck with that. Or do you just mean the maximum allocatable file size, in which case array-size limit varies dynamically with the contents of the array?

3) Abandoning the fixnum limit, especially given adjustability, is potentially really bad for performance even for arrays that aren't bigger than that limit; if you want really bad performance, you can roll it yourself.

4) The problem has historically been with array-size-limit rather smaller than the fixnum limit.

Speaking of which, does anyone remember the source of a quote that goes something like "There's a problem with arrays larger than memory; in particular, they have to be paged in twice to create them"?

paul
.

Relevant Pages

  • Re: Adjacent arrays in C99
    ... Same result as the first example -- undefined behavior. ... terms of a pointer pointing into, or one past, 'an array object'. ... Standard says that no restrictions apply on what implementations ...
    (comp.std.c)
  • Re: SSCANF
    ... This gives undefined behavior. ... You're trying to modify ... in this context will evalutate to pointers to their ... array of three char). ...
    (comp.lang.c)
  • Re: The value of variables
    ... I write a programe as follows,and compile successfuly. ... end of an array invokes undefined behavior after which *anything* is ... including the nul character. ...
    (comp.lang.c)
  • Re: usage of size_t
    ... size_t is the type yielded by the sizeof operator. ... an array definition ... has chosen to define an extension for the undefined behavior. ... for a moment it isn't (ie assume temporarily the declaration is ...
    (comp.lang.c)
  • Re: 3 questions about arrays
    ... If yes then it's undefined behavior. ... it only has to provide bigger fixnums. ... handle even if it means that part of the array would be in swap memory. ... each AREF would imply a bignum multiplication, ...
    (comp.lang.lisp)