Re: GC performance - GC fragility
- From: Andre Kaufmann <andre.kaufmann_re_move_@xxxxxxxxxxx>
- Date: Sat, 26 Jan 2008 17:17:17 +0100
> You are testing only the raw speed of allocating and freeing memory
> and without the cost of accessing elements in the allocated memory
> continuously, where GC is moving the memory while the code is running
> and WIN32 is not moving it.
Yes, but when Win32 is not moving the memory (it's always accessing the same location as you said) and GC is permanently moving ahead and freeing the memory, why has the Win32 heap been that slow - it has been only a simple "alloc 20 bytes" call to the memory manager ? It hasn't to search for an empty block, it should be nearly as fast as the GC one ?
I have allocated about 40 MB and the managed application has been using 5 MB system memory - so the 5 MB must have been touched multiple times and regarding your argumentation it must have been slower - or let's say at least shouldn't be (significantly) faster.
One argument could be that memory linearly can be accessed faster, than by random access. But that would speak for GC.
Also I don't think that the native heap has a much better cache locality. Think of a native heap which has
1000 entries of the type:
[60 bytes free] [40 bytes allocated] [60 bytes free] [40 bytes.....]
{ it's called heap fragmentation }
What will happen if the applications now wants to allocate 80 bytes ?
Every entry has to be checked and touched. Not quite local (for this example).
There are many other reasons why managed applications are slower than native ones. There are many reasons why optimized assembly is still much faster than compiled native code.
And I agree with you that cache locality and memory usage has a significant influence on the performance of applications.
But I don't think the GC to have generally a negative impact on the performance of managed applications.
Andre
.
- Follow-Ups:
- Re: GC performance - GC fragility
- From: Micha Nelissen
- Re: GC performance - GC fragility
- References:
- GC performance - GC fragility
- From: Eric Grange
- Re: GC performance - GC fragility
- From: Atmapuri
- GC performance - GC fragility
- Prev by Date: Re: A funny yet crazy extreme test on Delphi 7 compiler
- Next by Date: Re: A Tale of Two Memory Managers (long)
- Previous by thread: Re: GC performance - GC fragility
- Next by thread: Re: GC performance - GC fragility
- Index(es):
Relevant Pages
|
