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)
