dev-cpp-users Mailing List for Dev-C++

http://actv-tec.co.il/FAT.html
 		 	   		  

http://www.locandalemandriane.it/index04.html 
 		 	   		  

http://www.teichmannonline.de/index02.html  
 		 	   		  

http://barnaciber.net/index04.html 
 		 	   		  

Deepesh Kapadia wants you to use Dropbox to sync and share files online and across computers.

Get started here: http://www.dropbox.com/link/20.02B0p-c3XP/NjY5OTQ4NjU4Nw?src=referrals_bulk9

- The Dropbox Team

____________________________________________________ 
To stop receiving invites from Dropbox, please go to http://www.dropbox.com/bl/df1e87d8f4ca/dev-cpp-users%40lists.sourceforge.net

http://giovaninzago.org/click/click.html
 		 	   		  

http://sebastienlarousse.teria.org/OK.html/OK.html
 		 	   		  

http://www.os-cerkno.si/OK.html/OK.html
 		 	   		  

Note that virtual memory allows overcommit, i.e. the total amount of
memory pages can be more than the total amount of physical memory. What
doesn't fit in RAM will have to be swapped to disk.

But an important issue is the address space of the computer. 32-bit
Windows have a physical limitation of between 2 and 3 GB - actual figure
depends a bit on what version of Windows.

Between multiple applications, it's possible to allocate more memory than
what may be physically allocated.

But a single process can't do that. Variables within a process can't be
overlapping so if the OS have a limitation of 2 GB addressable RAM, then a
single process can't get past this (including stack) even if the machine
have 4GB of physical RAM (some of which are used by the OS and some are
wasted) and it also doesn't help if the swap file is 10 GB large.

So a 32-bit Windows installation will never be able to create an array
that requires more than about 2-3 GB before running out of physical
address range to map in RAM to.

Another thing is that a call to malloc() requesting a huge memory block
can instantly return with a pointer - no swapping needed. But as soon as
the program tries to fill the memory region, the OS may have to swap out
other programs or variables just to find some RAM to map into the
allocated memory region.

When it is needed to work with structures that are larger than the
addressable memory range the OS/hw combo can handle, then you must instead
work with a physical file and either let the OS create a memory mapping
between a region of the file and a memory buffer, or you must manually
read/write/cache blocks of the file into RAM. So with a 3TB Western
Digital HDD, you can work with a 3TB large array - but the running time of
the application will be very, very large.

/pwm

On Wed, 9 Feb 2011, J Glassy wrote:

> 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
>
> ------------------------------------------------------------------------------
> 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
>

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

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

http://comix.hellospace.net/main_link.html
 		 	   		  

http://ansan.dothome.co.kr/mainlink.html
 		 	   		  

http://kuohsiang.com.tw/mainlink.html
 		 	   		  

http://vicariomanguan.com/mainlink.html