Re: what is the proper way to read architecture limits

On 16.03.2015 10:57, Jean Saint-Remy [email protected] [ocaml_beginners] wrote:
> Hi
>
> I was trying to determine what is the maximum hashtable length in core, but it did
> not go so well.
> The max_table_length is defined as
> let max_table_length = Int_pow2.floor_pow2 Sys.max_array_length
>
> which would indicate the smallest power of two of Sys.max_array_length. At which
> point would you encounter an int overflow then? These are quite large numbers and we
> should never encounter them in our programs. Maximum string length has 17 digits and
> max int has 19 digits. I could not pronounce the Sys.max_array_length number, but it
> would appear the max hashtable size I estimate to be a quadrillion number. What is
> the right answer?
>
> Sys.max_array_length returns -: int = 18014398509481938 which would read, of course
> depending where you are, 180 quadrillion 143 trillion 985 billion 94 million 481
> thousand 983. This is a lot bigger still than the Sys.max_string_length -: int =
> 144115188075855863 that reads 144 quadrillion 115 trillion 188 billion 75 million 855
> thousand 863. You are not very likely to encounter a max int or Int64.max_int for
> that matter.
> String.length (string_of_int max_int) returns -: int = 19 with max_int of
> 4611686018427387903. Which would read
>
> 4 quintillion (exa) 611 quadrillion (peta) 686 trillion (tera) 18 billion (giga) 427
> million (mega) 387 thousand (kilo) 903. A max_int + 1 continues to count upwards, but
> returns a negative sign indicating an overflow. A max hashtable size would be bigger
> than max string length but considerably smaller than a max int. Operations on that
> big of an hashtable would be painfully slow.
>
> With kind regards,
>
> jean
>

No answers yet? Every question deserves a reaction.

But I am myself not sure how to interpret your question.

Do you not trust the values Sys.max_array_length and max_int?

Or do you mean that an a 64 bit machine using all address space -- that is
180 quadrillion 143 tril... bytes --  would be painfully slow? ;-)

/Str.