new D2.0 + C++ language

[Craig Black]

"Robert Jacques" <sandford at jhu.edu> wrote in message 
news:op.uq0ng1we26stm6 at sandford.myhome.westell.com...
> 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.

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