Re: [Dev-C++] MAXIMUM Memory Allocation in C

Daniel,

 Here is a quick shot at a reply to a complex issue, with this
disclaimer: fully understanding memory management in ANSI C/C++ takes
some people years. To REALLY understand it, you should become
acquainted with basic virtual-memory-management (VMM) theory and
practice  as implemented on your operating system, and anything you
can learn about how OS kernels work will help very much. But in
practice, very few application programmers understand this beyond the
minimum they need to get every day work accomplished.

-- There are many, many good books that address memory management in
ANSI C to some degree or other.  Start with K&R's books, and P.J.
Plaugher's books are above average on this as well, including full
info on the standard library.  When ready, you may want to read Peter
Van der Linden's Expert C , Deep C Secrets.  This book is a-typical in
how well he addresses memory and pointer arithmetic much better than
most.  Again, there are many others; just Google ANSI C memory
management and/or books.

--Memory management on a Win32 environment can be complex depending on
what you're trying to accomplish. If you can afford it, the more
physical memory (RAM) you can add to your working PC the better,
especially given the size of problems you appear to be wanting to
address.  Memory these days is the cheapest it has ever been, and time
is never cheap.

--At an OS level, physical memory is exposed by the kernel to "user
processes" via layered abstractions, made possible by the OS' virtual
memory manager.  Through swap memory (backing store actually managed
as a binary disk file), the OS can make more memory available to user
processes than actually exists as physical memory; this is generally
true for both Win32 as well as Linux, though each OS accomplishes this
via slightly different mechanisms.

--It is possible on most OS to adjust the virtual memory high water
mark by increasing the size of the virtual memory paging file or
"space"; simplistically, on Linux one would increase the size of the
swap partition. This can be easily be done on Windows OS as well; here
is a link explaining one way to do this, though there are other ways:

 http://www.ehow.com/how_2226129_size-paging-file-windows-xp.html.

  Please keep in mind that when you simply increase the size of the
virtual paging space this way, you're not adding to physical memory,
and when a process USES this capability, it will result in typically
much slower memory accesses due to the need to page
least-recently-used blocks in and out of the portion of memory
implemented as a binary disk file. OS try their best to do this
efficiently, and today use very complex, multi-layered caching schemes
to try to optimize overall system wide performance -- but still, its
not magic and you see a performance hit.

--From within an application, you generally request memory either from
two classes of memory -- the stack or the heap.
  Stack memory and methods to work with this are typically referred to
as "static memory" and heap memory is typically referred to as
"dynamic memory".

-- Dynamic memory is almost ALWAYS what application programmers want
to use. In ANSI C, as you know, you explicitly allocate blocks of
memory, per variable, using calloc().  Definitely avoid using malloc()
since memory returned by malloc() is NOT initialized and you
absolutely want to start each variables life-cycle in an application
in a known state (e.g. initialized).

-- Dynamic memory MUST be released when you are done with it, in order
to be a polite OS citizen and return it to the free pool so that other
processes can get access to it.
- In a procedural language like ANSI C, or C++ (including Dev-C++
etc), automatic variables are assigned memory off the stack, but this
is a very limited resource, sometimes as little as 10Kb for some
environments, but this can vary -- good rule of thumb: don't COUNT ON
USING STACK MEMORY.  Here is a quick code-snippet example of an
automatic variable using stack memory, vs. dynamic memory.


#include <stdio.h>
#include <stdlib.h>

 int main(int argc,char *argv[])
 {
   int a   = 0 ; /* uses sizeof(int) bytes off the stack */
   float x = 0.0 /* uses sizeof(float) bytes (on a PC, an IEEE single
precision real is 4 bytes) from the stack */
   float y[100] = {0}; /* uses sizeof(float) * 100, so 400 bytes off
the stack */

   /* here is an example of memory taken off the heap. this is often
called "dynamic memory allocation" */
   int r=0, c=0, k=0;
   int nRows     = 1024;
   int nColumns = 768;
   int nElements = nRows * nColumns;
   double *array = NULL;

   /* request (dynamic) memory off the heap, and warn user if this
amount is not available */
   if((array = (double *)calloc(sizeof(double), nElements))==NULL)
   {
     printf("Failed memory request for %d elements of double\n",nElements);
     exit(-1);
   }

   /* do something with the array here ... dummy placeholder logic is here */
   for(k=0,r = 0; r < nRows; r++)
      for(c=0; c < nCols; c++)
                  array[k++] = 999.9 ;

   /* later, when done, release it back to the free pool */
   free(array);

  exit(0);
 }  /* end:: main()*/

Hope this helps.

cheers,
joe


On Wed, Feb 9, 2011 at 8:48 AM, Daniel Albrecht
<dan...@jr...> wrote:
> Hello,
>
>   My PC is:    Fujitsu-Siemens:        CELSIUS model
>                        XEON(TM) CPU: 2.8 GHz + 1 Gbytes RAM
>                        running on XP Professional (2002) Service Pack: #3
>
> I simply program in C language with Dev-C++ Bloodshed 4.9.9.2.
> It works beautifully !!!
>
> QUESTIONS:
> 1. WHERE can I find the standard library information ?
>        I do NOT find it on: http://www.bloodshed.net/devcpp.html
>
> 2. WHERE can I find info or the best approach to understand memory
>        allocation [malloc()] ?
>        at:     double array[524288][360] == ~1.5 Gbytes, it still works !
>        at:     double array[1048576][360] == ~3.0 Gbytes, it seems to stop
> !
>
>        what about virtual memory behaviour/settings on my PC ?
>
> Best wishes.
>
> Daniel Albrecht
>
>
> --
> Daniel Albrecht (PhD)
> JRC - IPSC - EAS Unit
>
>----------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

------------------------------------------------------------
Joseph Glassy
Lead Software Engineer, F/T & L4 C
NASA Measures (Freeze/Thaw),Rm CFC 424
College of Forestry and Conservation
Univ. Montana, Missoula, MT 59812

Lupine Logic Inc.
www.lupinelogic.com
Scientific and Technical Programming