new D2.0 + C++ language
Robert Jacques
sandford at jhu.edu
Thu Mar 19 05:18:23 PDT 2009
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).
More information about the Digitalmars-d
mailing list