new D2.0 + C++ language

Robert Jacques sandford at jhu.edu
Wed Mar 18 18:52:03 PDT 2009


On Wed, 18 Mar 2009 13:48:55 -0400, Craig Black <cblack at ara.com> 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.



More information about the Digitalmars-d mailing list