gc vs explicit

[Dave]

zz wrote:
> Walter Bright wrote:
>> zz wrote:
>>
>>>  From my point of view these tests are not really nessesary on my 
>>> side since I still continue using D and I belive that someday the 
>>> memory stuff will be optimized.
>>
>>
>> One thing that is happening is that the C++ code allocates memory, it 
>> never frees it. The same with the D code.
> 
> Not until it's out of scope (in this case main).
> 

With that in mind, I wrapped your original code in a loop for 10 iterations and decreased the inner 
loop to 100000.

C++ (NedAlloc):
Total Element count: 1000000
5.438000

D:
Total Element count: 1000000
1.360000

Because it's not doing all of it's allocation in one tight loop, maybe this better 'emulates' a 
'typical' service or client application? Point is, have you and your coworker from the OP actually 
tried D in a couple of real-world application examples?

Quote: "While he liked that language and said the he might actually use it to prototype idea's, he 
will not use it in production code due to the performance."

That sounds like me two years ago (and D hasn't gotten all that much faster since then) <g>

Don't take this as some sort of attack -- you bring up some very good points. And I agree that the 
GC performance should be looked at (and that great performance is critical), but I'm wondering if D 
is getting a fair shake in your shop?

Even if you had to spend 10% development time to hoist some allocations out of loops with D, if you 
save 20% developing the first-cut you'll end up better off ;)

>> What happens with a garbage collector is it gets new chunks of memory 
>> from the operating system as it needs it. But before it does, it runs 
>> a collection cycle.
> 
> Would something like dlmalloc by Doug Lea make a difference in D, 
> someone suggested trying it out so I tested it using DMC on some C code 
> and there was a big difference the two compiled versions (Numbers are 
> below and I was supprised).
> 
>> So in the D version, it will be running probably several collection 
>> cycles (accomplishing nothing), while the C++ version does not. This 
>> will make the gc version slower.
>>
>> To get better numbers, one can add calls to gc.disable() and 
>> gc.enable() to tell the gc that there is no point to running a 
>> collection cycle for this section of code.
> 
> The above is something that, i'll not do (In DMC i can get better 
> numbers by just changing my allocator how can I go about it in D).
> 
> Zz
> 
> -----------------------------------------------
> - Default memory allocator
> dmc -o+all test.c
> Capacity C: 1048576  Count: 1000000
> 
> ContextSwitches - 19954
> First level fills = 0
> Second level fills = 0
> 
> ETime(   0:00:06.562 ) UTime(   0:00:06.015 ) KTime(   0:00:00.375 )
> ITime(   0:00:03.828 )
> 
> 
> -----------------------------------------------
> dmc -DREPLACE_SYSTEM_ALLOCATOR -o+all test.c
> Capacity C: 1048576  Count: 1000000
> 
> ContextSwitches - 3092
> First level fills = 0
> Second level fills = 0
> 
> ETime(   0:00:01.250 ) UTime(   0:00:00.968 ) KTime(   0:00:00.250 )
> ITime(   0:00:00.796 )
> 
> Note: I used dlmalloc Version pre-2.8.4 Wed Aug  2 14:13:56 2006 which 
> comes with nedmalloc.
> The current version is 2.8.3 and ptmalloc3 comes with an earlier version 
> of the one used above.