By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,002 Members | 1,286 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,002 IT Pros & Developers. It's quick & easy.

What is the largest array I can allocate??

P: n/a
I was able to allocate a single array having 2.6GB (ie. w/ 700200000
elements of type float) yet when I did a cpuinfo on my computer, it
showed a cache size of 256KB and 1GB of memory. What happened??? I
thought new returns a contiguous block of memory???

Jul 23 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a

<bl**********@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
I was able to allocate a single array having 2.6GB (ie. w/ 700200000
elements of type float)
Note that type 'float' does not have the same size on
all implementations. The total memory for that
many type 'float' objects could easily be different
on another system.
yet when I did a cpuinfo on my computer, it
showed a cache size of 256KB and 1GB of memory. What happened???
I suspect your platform uses some sort of virtual memory
mechanism. Microsoft Windows perhaps?

I
thought new returns a contiguous block of memory???


It does. But the address range of that memory need not
correspond to your platform's underlying 'real' addresses.
Your system will provide each program a certain size 'address
space'. That's the range of addresses which your program will
'see' (also subject to more adjustments by your C runtime).

As far as your question "how much can I allocate?", the
answer to that depends entirely upon the capabilites of
your platform and your C implementation. From the perspective
of your C implementation, the limit is the maximum value
representable by the type 'size_t', declared by <stdlib.h>
(and a few other headers).

-Mike
Jul 23 '05 #2

P: n/a
bl**********@gmail.com wrote:
I was able to allocate a single array having 2.6GB (ie. w/ 700200000
elements of type float) yet when I did a cpuinfo on my computer, it
showed a cache size of 256KB and 1GB of memory. What happened??? I
thought new returns a contiguous block of memory???


How is what you obtained from 'cpuinfo' contradicting your knowledge
that 'new' returns a contiguous block? Please try to stay within C++
language terms while explaining that (if you can). IOW, how does the
fact that "it showed a cache size of ..." prove that 'new' returned
a block that is (or isn't) contiguous?

V
Jul 23 '05 #3

P: n/a
let me rephrase the question (given that I have a dell machine w/ xeon
processor running fedore core 3)
1. Is heap a region of RAM?
2. Why did my program run out of memory at precisely 2.6GB? I knew it
was 2.6GB because I kept playing w/ the array'size which was,
nevertheless, time-consuming. Any faster alternative?

Jul 23 '05 #4

P: n/a

<bl**********@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
let me rephrase the question (given that I have a dell machine w/ xeon
processor running fedore core 3)
1. Is heap a region of RAM?
That is not specified by the standard. The implementation has to act as if
the memory allocated by new is contiguous, but how it accomplishes that is
not specified. The data could be stored mechanically by balls dropping into
buckets, as far as the standard is concerned. :-)
2. Why did my program run out of memory at precisely 2.6GB? I knew it
was 2.6GB because I kept playing w/ the array'size which was,
nevertheless, time-consuming.
We don't know. Perhaps that's what your operating system settings specify.
It's not a subject covered by the language specifications. Perhaps you
could ask in a newsgroup or forum dedicated to your operating system.
Any faster alternative?


To what? Testing?
I think what you want is to research "virtual memory", especially how it
relates to your specific operating system. From a C++ standpoint, it's
irrelevant.
-Howard

Jul 23 '05 #5

P: n/a
bl**********@gmail.com wrote:
let me rephrase the question (given that I have a dell machine w/ xeon
processor running fedore core 3)
The hardware on which you run your program is irrelevant in a language
newsgroup. If you think it's relevant, your question must be off-topic.
1. Is heap a region of RAM?
No. Yes. Maybe. How can this be answered? The former is a concept
related to a running program, the latter is hardware. C++ programs run
on a virtual machine where certain things are true by definition, like
that any block you get from 'new' is contiguous.
2. Why did my program run out of memory at precisely 2.6GB? I knew it
was 2.6GB because I kept playing w/ the array'size which was,
nevertheless, time-consuming. Any faster alternative?


You should ask in a newsgroup related to your OS/platform. I'm afraid
those questions cannot be answered in terms of C++ language. In C++
it is enough to allocate and deallocate arrays of some sizes narrowing
down the maximum size that can be allocated, but on many platforms the
memory when 'delete'd is not immediately returned to the process thus
making a simple binary search for the maximum impossible.

V
Jul 23 '05 #6

P: n/a
bl**********@gmail.com schrieb:
let me rephrase the question (given that I have a dell machine w/ xeon
processor running fedore core 3)
1. Is heap a region of RAM?
No and yes. Heap is a region of "virtual memory". The virtual memory is
managed by the operation system (OS), like Linux, Windows etc.

Every program gets it's own virtual adress space from the OS.

If a program requests more memory than the amount of available RAM, the
OS swaps parts of the RAM to harddisk ("swapping"). This process
is completly transparent to the application.
2. Why did my program run out of memory at precisely 2.6GB? I knew it
was 2.6GB because I kept playing w/ the array'size which was,
nevertheless, time-consuming. Any faster alternative?


Using a large File and programming your own data cache management
could be faster than letting the OS do the "swap-game". But this
is a little more complex than using an array.

Best regards
Jul 23 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.