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.