Re: coded size limits on Perl data types?

2016-09-13 Thread Darren Duncan
Thank you for this Timo, and to everyone else who replied.  It did indeed 
address what I wanted to know. -- Darren Duncan


On 2016-09-13 5:15 AM, Timo Paulssen wrote:

I'll answer based on the data structures MoarVM uses internally:

On 09/13/2016 05:13 AM, Darren Duncan wrote:> (Pretend the actual hardware has
infinite memory so we wouldn't run > out of hardware first.) > > 1.  Maximum
size of a (non-machine) integer? We're using libtommath, which declares the
"used" and "alloc" fields of the mp_int as "int", iow a 32bit signed (???) 
integer.


2.  Maximum number of elements in an array?  MVMArray declares the "elems", "start" and 
"ssize" fields to be MVMuint64, so

they can become quite a bit bigger than strings.


3.  Maximum number of elements in a hash?  the "uthash" library we're using declares the 
"num_buckets" and "num_items"

fields as unsigned (so 32bit unsigned integer).


4.  Maximum number of bytes/codepoints/etc in a character string?  MVMString declares its 
"num_graphs" as a MVMuint32, but a graph can be

multiple codepoints and as such multiple bytes when encoded.


Following the above, does the Perl 6 language specify any such  > limits, or 
does it define the above things to be infinite? I don't think it

does.


Hope that helps!
   - Timo




Re: coded size limits on Perl data types?

2016-09-13 Thread Timo Paulssen
On 09/13/2016 03:12 PM, Timo Paulssen wrote:> If one big integer is
allowed to be 14 gigabytes big (if we use the > default of 28 bits per
"mp digit"; it's also possible to use 31 or > 60.), we can still safely
say "limited only by memory" for now.

Something else that makes this pretty difficult is that our big ints
currently act immutable, so if we ++ a number all the way up to 14
gigabytes, we'll keep around a whole bunch of older big ints until the
GC thinks it has to kick in ...

If you have an exabyte of RAM or a significant amount of swap space, you
ought to be able to work with this, though.

Be prepared for The Slow, though :)


Re: coded size limits on Perl data types?

2016-09-13 Thread Elizabeth Mattijsen
> On 13 Sep 2016, at 14:15, Timo Paulssen  wrote:
> 
> I'll answer based on the data structures MoarVM uses internally:
> 
> On 09/13/2016 05:13 AM, Darren Duncan wrote:
> 
> > (Pretend the actual hardware has infinite memory so we wouldn't run
> > out of hardware first.)
> > 
> > 1.  Maximum size of a (non-machine) integer?
> 
> 
> We're using libtommath, which declares the "used" and "alloc" fields of the 
> mp_int as "int", iow a 32bit signed (???) integer.

eh, but Int is supposed to be a bigint, only limited by memory, no?


Liz

coded size limits on Perl data types?

2016-09-12 Thread Darren Duncan

Ostensibly Perl 6 is meant to be a language ready for the next hundred years.

As such, I am wondering where either Perl 6 or its implementations have 
hard-coded limits based on current or projected hardware limitations, or where 
they don't.


Examples of what I would like to know, do any limits exist on each of the 
following and if so then what are they?


(Pretend the actual hardware has infinite memory so we wouldn't run out of 
hardware first.)


1.  Maximum size of a (non-machine) integer?

2.  Maximum number of elements in an array?

3.  Maximum number of elements in a hash?

4.  Maximum number of bytes/codepoints/etc in a character string?

Possible reasons for the limits include that a fixed-size integer may be used to 
record the count of elements in a collection, including to mark the size of a 
collection having pieces of a bigint, or using a fixed-size integer for indexing 
into an array, say.


Following the above, does the Perl 6 language specify any such limits, or does 
it define the above things to be infinite?


Do any Perl 6 implementations support the above being infinite, or do they use 
fixed-size numbers to track anything that would effectively limit the types?


Thank you.

-- Darren Duncan