March 21, 2009
"Robert Jacques" <sandford@jhu.edu> wrote in message news:op.uq0ng1we26stm6@sandford.myhome.westell.com...
> On Wed, 18 Mar 2009 13:48:55 -0400, Craig Black <cblack@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 

March 21, 2009
Christopher Wright wrote:
> Games have strict performance requirements that a stop-the-world type of garbage collector violates. Specifically, a full collection would cause an undue delay of hundreds of milliseconds on occasion. If this happens once every ten seconds, your game has performance problems. This is not true of pretty much any other type of application.

If you spend hundreds of milliseconds on garbage collection every ten second, you spend multiple percent of your total execution time on garbage collection.  I wouldn't consider that acceptable anywhere.


-- 
Rainer Deyke - rainerd@eldwood.com
March 21, 2009
Hello Rainer,

> Christopher Wright wrote:
> 
>> Games have strict performance requirements that a stop-the-world type
>> of garbage collector violates. Specifically, a full collection would
>> cause an undue delay of hundreds of milliseconds on occasion. If this
>> happens once every ten seconds, your game has performance problems.
>> This is not true of pretty much any other type of application.
>> 
> If you spend hundreds of milliseconds on garbage collection every ten
> second, you spend multiple percent of your total execution time on
> garbage collection.  I wouldn't consider that acceptable anywhere.
> 

If you spend a few 0.1ths of a ms every 10 ms on reference counting, smart pointers or passing around other meta data it's the just as bad. I have no data but even worse would be, as I expect is true, if non GC apps end up being architected different to make memory management easier (if so, you can bet money it won't be faster as result). 


March 21, 2009
Rainer Deyke wrote:
> Christopher Wright wrote:
>> Games have strict performance requirements that a stop-the-world type of
>> garbage collector violates. Specifically, a full collection would cause
>> an undue delay of hundreds of milliseconds on occasion. If this happens
>> once every ten seconds, your game has performance problems. This is not
>> true of pretty much any other type of application.
> 
> If you spend hundreds of milliseconds on garbage collection every ten
> second, you spend multiple percent of your total execution time on
> garbage collection.  I wouldn't consider that acceptable anywhere.

I was pulling numbers out of my ass. If I wanted to do a proper job, I would have built a large application and modified druntime to get proper timings.

0.1 seconds out of every ten is a small amount to pay for the benefits of garbage collection in most situations. (Most GUI applications are idle most of the time anyway.) I did, however, specifically make the point that it's unacceptable in some situations. These situations may be your situations. Even so, the garbage collector might not be that slow. (And for what it's doing, that seems pretty fast to me.)

It would be cool if the GC could watch for what pages have been written to since the last collection and only bother looking through them. That would require some additional accounting. On Windows, there's a system call GetWriteWatch that works in that regard, but on Linux, the only solution I've seen is marking the memory readonly and trapping SIGSEGV. That would be pretty expensive.
March 21, 2009
Hello Christopher,

> 
> It would be cool if the GC could watch for what pages have been
> written to since the last collection and only bother looking through
> them. That would require some additional accounting. On Windows,
> there's a system call GetWriteWatch that works in that regard, but on
> Linux, the only solution I've seen is marking the memory readonly and
> trapping SIGSEGV. That would be pretty expensive.
> 

http://libsigsegv.sourceforge.net/

"""
What is libsigsegv?

This is a library for handling page faults in user mode. A page fault occurs when a program tries to access to a region of memory that is currently not available. Catching and handling a page fault is a useful technique for implementing:

...
   * generational garbage collectors,
"""



March 21, 2009
Christopher Wright wrote:
> I was pulling numbers out of my ass.

That's what I assumed.  I'm a game developer.  I use GC.

> 0.1 seconds out of every ten is a small amount to pay for the benefits of garbage collection in most situations.

GC is useless for resource management.  RAII solves the resource management problem, in C++ and D2.  GC is a performance optimization on top of that.  If the GC isn't faster than simple reference counting, then it serves no purpose, because you could use RAII with reference counting for the same effect.

(No, I don't consider circular references a problem worth discussing.)


-- 
Rainer Deyke - rainerd@eldwood.com
March 21, 2009
Weed пишет:
> Hi!
> 
> 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++:

at least to something like this idea? )
March 21, 2009
Weed pisze:
> Weed пишет:
>> Hi!
>>
>> 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++:
> 
> at least to something like this idea? )

The idea could be ok but have you written a compiler or specification? Or is it wishful thinking like let's make the language that's productive to the skies while faster than asm? ;)

Cheers
March 21, 2009
Piotrek пишет:
> Weed pisze:
>> Weed пишет:
>>> Hi!
>>>
>>> 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++:
>>
>> at least to something like this idea? )
> 
> The idea could be ok but have you written a compiler or specification?

My experience in the creation of the compilers is reduced to half-read book "Compilers: Principles, Techniques, and Tools".

It was easier to write the differences from D, as fully to specification - I hoped that receive point to some fundamental problems, but there seems  all to be good (excluding holy war about GC, of course)

> Or is it wishful thinking like let's make the language that's productive to the skies while faster than asm? ;)

No. )
I'm not suggesting anything new, it is suggested that all the
time-tested things.
March 21, 2009
Weed pisze:
> No. )
> I'm not suggesting anything new, it is suggested that all the
> time-tested things.

OK. I tell you what I think. D is a well designed language. What you suggest is some kind of hack to that language. I don't think there's much interest in it. As you said you don't have much experience in writing compilers (neither do I) but you should know how hard is to keep the design points all the way a language works. Walter spent many years on it. Form my point of view he does the best (of course there are bugs but  when I write something in D I'm so glad I don't have to to do it in something else).

Cheers