new D2.0 + C++ language

[Weed]

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!

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

Who?

> 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)