Re: Maximum Array int is 330 M, not 2.1 billion

Tech-Archive recommends: Fix windows errors by optimizing your registry

raylopez99 wrote:
The maximum int for an array on my machine (a Pentium IV with 2 GB
RAM) is < 330 Million...before you get an "out of memory" exception.
I simply filled an array of this size with ints...I got as far as 320
M. So, myArray[320000000] is a big as I can get.

In theory a 32 bit int is 2.1 billion,

If you're talking about the maximum value of a signed 32-bit int (2147483647), that's not relevant here, as managed allocation size isn't restricted to that. What is relevant is the address space limit of your application, which happens to be 2 GiB on 32-bit Windows, which happens to be the maximum value of a signed 32-bit int as well -- but this is coincidental. You can make Windows run with a 3 GiB virtual address space for each application, for example, and 64-bit applications have a (for now) unfathomably bigger limit that I can't recall right now, but you'll hit the limits of your physical memory far sooner than that.

but in practice, you cannot fill an array having anywhere near that
number of elements. I suspect that it's because every element of an array
takes up space equal to: 2.1E9/320E6 = 6.56 = 7 bytes of 32 bit memory

You suspect wrongly. There is no extra per-element overhead for managed arrays (there is some small per-object overhead, but that's for the array as a whole). So an array of 330 million integers takes up very close to 330e6 * 4 = 1.32 billion bytes, which is 1.23 GiB.

This is apparently the maximum amount of contiguous memory in your process' address space. You can probably squeeze more out of it by allocating smaller arrays to fill in the noncontiguous parts. You won't reach 2.0 GiB exactly in any case, because the runtime obviously needs memory too (and a small part of the address space is invalidated by the kernel), and you will never be able to exceed 2.0 GiB no matter how much physical memory you have, because your address space just isn't big enough.

--
J.
.

Relevant Pages

  • Re: 3 questions about arrays
    ... In order to print the elements of the array doesn't the ... If yes then it's undefined behavior. ... choosing the size of fixnums not the maximum size of arrays. ... 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. ...
    (comp.lang.lisp)
  • Re: Reversing Array Elements?
    ... Depends what you mean by "actually reverse the array". ... rather than a specification of the language. ... could make such a reordered copy in physical memory as an optimization. ...
    (comp.lang.fortran)
  • Re: Accessing Physical memory in windows 64bit
    ... No need to parse physical memory. ... The operative system provides that informtation via WMI In kernel-mode, ... and in user mode as an array of bytes already extracted for you. ...
    (microsoft.public.development.device.drivers)
  • Re: array inside a array!?
    ... >> array inside a array, like the below, ... C does not guarantee physical adjacency, ... physical memory at all. ... the publicly available last draft of the C99 standard. ...
    (comp.lang.c)
  • Re: Are array members guaranteed to be contiguous in physical memory?
    ... The Standard demands it. ... In 6.2.5 clause 20 the Standard guarantees that the array is ... not the physical memory of the hosting ... terrible burden on the compiler runtime environment as it has to have ...
    (comp.lang.c)