new D2.0 + C++ language

[Robert Jacques]

On Thu, 19 Mar 2009 07:32:18 -0400, Weed <resume755 at mail.ru> wrote:

> Robert Jacques пишет:
>
>>>
>>> Multiprocessing can only improve performance for tasks that can run in
>>> parallel.  So far, every attempt to do this with GC (that I know of)
>>> has ended up slower, not faster.  Bottom line, if GC is the
>>> bottleneck, more CPU's won't help.
>>>
>>> For applications where GC performance is unacceptable, we either need
>>> a radically new way to do GC faster, rely less on the GC, or drop GC
>>> altogether.
>>>
>>> However, in D, we can't get rid of the GC altogether, since the
>>> compiler relies on it.  But we can use explicit memory management
>>> where it makes sense to do so.
>>>
>>> -Craig
>>
>> *Sigh*, you do know people run cluster & multi-threaded Java apps all
>> the time right? I'd recommend reading about concurrent GCs
>> http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Stop-the-world_vs._incremental_vs._concurrent.
>> By the way, traditional malloc has rather horrible multi-threaded
>> performance as 1) it creates lots of kernel calls
>
> D2.0 with GC also creates lots of kernel calls!

*sigh* All memory allocation must make some kernel calls. D's GC makes  
fewer calls than a traditional malloc. Actually,  modern malloc  
replacements imitate the way GCs allocate memory since it's a lot faster.  
(Intel's threading building blocks mentions this as part of its marketing  
and performance numbers, so modern mallocs are probably not that common)

>
>> and 2) requires a
>> global lock on access.
>
> Who?

Traditional malloc requires taking global lock (and as point 1, often a  
kernel lock. Again, fixing this issue is one of Intel's TBB's  
marketing/performance points)

>> Yes, there are several alternatives available
>> now, but the same techniques work for enabling multi-threaded GCs. D's
>> shared/local model should support thread local heaps, which would
>> improve all of the above.
>
> It does not prevent pre-create the objects, or to reserve memory for
> them in advance. (This is what makes the GC, but a programmer would do
> it better)

I think the point you're trying to make is that a GC is more memory  
intensive. Actually, since fast modern mallocs and GC share the same  
underlying allocation techniques, they have about the same memory usage,  
etc. Of course, a traditional malloc with aggressive manual control can  
often return memory to the kernel in a timely manner, so a program's  
memory allocation better tracks actual usage as opposed to the maximum.  
Doing so is very performance intensive and GCs can return memory to the  
system too (Tango's does if I remember correctly).