On Thu, 19 Mar 2009 07:32:18 -0400, Weed <[email protected]> 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).
