"Robert Jacques" <[email protected]> wrote in message
news:[email protected]...
On Wed, 18 Mar 2009 13:48:55 -0400, Craig Black <[email protected]> wrote:
bearophile Wrote:
Weed:
> I want to offer the dialect of the language D2.0, suitable for use
where
> are now used C/C++. Main goal of this is making language like D, but
> corresponding "zero-overhead principle" like C++:
>...
> The code on this language almost as dangerous as a code on C++ - it
is a
> necessary cost for increasing performance.
No, thanks...
And regarding performance, eventually it will come a lot from a good
usage of multiprocessing, that in real-world programs may need pure
functions and immutable data. That D2 has already, while C++ is less
lucky.
Bye,
bearophile
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 and 2) requires a global
lock on access. 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.
I admit to knowing nothing about clusters, so my point does not apply to
them. Also note that I didn't say GC was not useful. I said GC can be a
bottleneck. If it is a bottleneck (on a single computer), throwing more
CPU's at it doesn't help. Why? The big performance problem with GC is with
large applications that allocate a lot of memory. In these apps, modern
GC's are constantly causing page faults because they are touching too much
memory.
I look forward to the day where all the GC problems are solved, and I
believe it will come. It would be really nice to have a faster GC in D.
However, I don't see how each processor working on a separate heap will
solve the problem of the GC causing page faults. But maybe I missed
something.
BTW, I don't use traditional malloc. I use nedmalloc and the performance is
quite good.
-Craig
