Oops, my mistake.  Yes, 195,000k.  That's what I get for posting something when I wasn't feeling well.

I meant to say, VC++ as requested.  I'm using cl 13.10.3077 for 80x86. Default options.

I used DMD because the comparison with DMC had already been made, but I didn't see anything equivalent for DMD.  DMD 0.162, by the way.

Thanks,
-[Unknown]


> Unknown W. Brackets wrote:
>> 10_000 chunks of 10_000 (freeing everything - CHUNKINC = 1):
>>
>> On startup...
>>     Mem usage: 612k
>>     VM Size: 240k
>>
>> After alloc:
>>     Mem usage: 119,504k
>>     VM Size: 195k
>  >
> Typo there, should be about VM Size: 195,000k.
> 
>> After free:
>>     Mem usage: 60,272k
>>     VM Size 98,296k
>>
> 
> You forgot to mention which compiler(and compiler version) was used. *g*
> 
> 
>>
>> DMD version... same constants.
> 
> DMD? Why not just use DMC?
> 

Walter Bright wrote:
> Serg Kovrov wrote:
> 
>> But that not worst part. Although I'm personally from C++ camp and I get used to GC. and see it as good thing. But, there is one big BUT! Currently GC do not return memory to OS, and that thing even I can't subdue. The only reason I choose 'native' (as opposite to VM) programming language is effective resource usage. I hate Java/.net gui applications because their memory consuming. I really appreciate developers that choose c/c++ to write small, memory effective, but yet feature-reach applications like FileZilla Server, uTorrent or Miranda IM.
>>
>> Most desktop applications (like text editors, news readers, web browsers, etc) must coexist with each other. That is, to use memory wisely and give it back if it not needed anymore. This 'upper water mark' approach in GC is just not acceptable.
> 
> 
> 1) Few programmers realize that C/C++'s malloc/free/new/delete *never* (and I emphasize NEVER) return memory to the operating system. All free/delete do is return memory to the memory pool managed by the runtime library, not the operating system. In order to actually return memory to the operating system, one has to write their own memory management code, which is a significant (and necessarily non-portable) effort. Hardly anyone does that.

I think this doesn't give a complete picture of the situation.

There is the need to give memory back to the OS (e. g. if a user
has just stopped working with a couple of 100 MB pictures).

Operating systems sometimes do offer mechanisms for this (e. g.
Windows has the GlobalAlloc/GlobalReAlloc/GlobalFree set of functions).
If you use a wrapper for memory allocation it is very easy to use
this efficiently (pure or mixed with malloc/realloc/free).

Bruno Medeiros wrote:
> Hum, I modified the program and tried 4 more tests:
> 
> Allocating 10000 (sequential) chunks of size 10000 bytes. Free them all.
> -> All the 100Mb of memory is returned to the OS.
> 
> Allocating 100000 (sequential) chunks of size 1000 bytes. Free them all.
> -> All the 100Mb of memory is returned to the OS.
> 
> Allocating 10000 (sequential) chunks of size 10000 bytes. Free only half of them, the even numbered ones, so that the total freed memory is not contiguous.
> -> Of the 50Mb memory free'd, about 30Mb of memory is returned to the OS. Expected due to page segmentantion/rounding.
> 
> Allocating 100000 (sequential) chunks of size 1000 bytes. Again free only the even numbered ones.
> -> 50Mb memory is free'd, but no memory is returned to the OS. Expected due to page segmentantion/rounding.
> 
> So it seems glibc does its best, it returns any page if it is all free. 

So it does seem to, and so my statement is obsolete.

Unknown W. Brackets wrote:
> Oops, my mistake.  Yes, 195,000k.  That's what I get for posting something when I wasn't feeling well.
> 
> I meant to say, VC++ as requested.  I'm using cl 13.10.3077 for 80x86. Default options.
> 

Ah, Visual Studio 2003

> I used DMD because the comparison with DMC had already been made, but I didn't see anything equivalent for DMD.  DMD 0.162, by the way.
> 

Walter had mentioned before that DMD's memory manager use C's malloc and free to allocate, so no difference in return behavior is to be expected.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
>
> Walter had mentioned before that DMD's memory manager use C's malloc and free to allocate, so no difference in return behavior is to be expected.

It actually uses VirtualAlloc, though malloc is a failover option in GDC's memory manager.


Sean

Sean Kelly wrote:
> Bruno Medeiros wrote:
>>
>> Walter had mentioned before that DMD's memory manager use C's malloc and free to allocate, so no difference in return behavior is to be expected.
> 
> It actually uses VirtualAlloc, though malloc is a failover option in GDC's memory manager.
> 
> 
> Sean

Hum, didn't Walter once mention that nearly all compiler implementations of new and delete used malloc? I assumed his compilers where one of such (didn't look at Phobos). Perhaps that simply was not the case. Or perhaps he just meant C++ compilers?


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Sean Kelly wrote:
>> Bruno Medeiros wrote:
>>>
>>> Walter had mentioned before that DMD's memory manager use C's malloc and free to allocate, so no difference in return behavior is to be expected.
>>
>> It actually uses VirtualAlloc, though malloc is a failover option in GDC's memory manager.
> 
> Hum, didn't Walter once mention that nearly all compiler implementations of new and delete used malloc? I assumed his compilers where one of such (didn't look at Phobos). Perhaps that simply was not the case. Or perhaps he just meant C++ compilers?

He meant C++ compilers.  But the situation in D is somewhat different because of garbage collection.  malloc is itself a memory allocator and D's GC is also an allocator, so having D's allocator call malloc would be like one retail store buying all their products from another retail store in bulk--it's much more efficient just to order from the distributer :-)


Sean