RE: Question about table arrays

["Dolan, Ryanne Thomas (UMR-Student)" <rtdmr6@...>]

using 'sizeof(char)' doesn't add instructions; as you said it is just translated to 1 by the compiler, and it is more meaningful than '1'.  There is no reason to remove it.

-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br on behalf of Mike Pall
Sent: Mon 1/9/2006 12:59 PM
To: Lua list
Subject: Re: Question about table arrays
 
Hi,

Rici Lake wrote:
> This would appear to restrict the array part of a table to 64 million 
> elements even on ILP64 architectures.

I asked this back then, when I sent my 64 bit patches:
  http://lua-users.org/lists/lua-l/2004-11/msg00032.html

I never got a reponse, but the define was quietly changed from
24 to 26. :-)

> So why 26?

floor(log(INT_MAX/sizeof(TValue))/log(2)) (for a 16 byte TValue).
Ok, so this limit only applies to 32 bit platforms. But there are
several places in the source which index the array part with an
int. This is a 32 bit type on LP64 (most POSIX) and LLP64 (Win64)
platforms.

I guess when you approach these limits (i.e. a single array with
a size of more than 1 GB), you might want to consider alternate
approaches (e.g. userdata). I had to do this because it's no fun
when the GC sweeps such a table ever so often (traversetable() is
atomic even in Lua 5.1).

[Alas, a non-atomic traversal doesn't help. One really needs to
completely avoid the traversal, because D-cache pollution kills
the performance. I'm not sure generational GC would help.]

> On the other hand, if the Lua instance were compiled with lua_Number as 
> a (single-precision) float, then the array part could grow to a larger 
> size than could be represented as an integral lua_Number, which seems 
> like it ought to trigger an error of some sort.

This is not a problem because you can only create number objects
for numbers which are representable with lua_Number. So even if
the array grows larger (with a sparse tail), you just can't set
or get these elements because you are lacking the proper key.

Not having a representation for contiguous integral numbers with
a precision of more than 24 bits may lead to problems with loops,
though. But I don't think there is any part in the Lua core or
standard libraries which fails in this case (all loops are done
with int32 cast to lua_Number).


BTW: Speaking of types and sizes ... anyone noticed sizeof(char)
sprinkled throughout the source? Funny enough, but this doesn't
accomplish anything. sizeof(char) is _always_ 1 (that's how
sizeof quantities are defined). One realls wants to check
CHAR_BIT (but the Lua core doesn't). I have some doubts that Lua
works on systems where this is not 8. So one might as well remove
the superfluous code.

Bye,
     Mike

<<winmail.dat>>