View mode: basic / threaded / horizontal-split · Log in · Help
March 21, 2009
Re: new D2.0 + C++ language
"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
Re: new D2.0 + C++ language
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
Re: new D2.0 + C++ language
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
Re: new D2.0 + C++ language
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
Re: new D2.0 + C++ language
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
Re: new D2.0 + C++ language
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
Re: new D2.0 + C++ language
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
Re: new D2.0 + C++ language
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
Re: new D2.0 + C++ language
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
Re: new D2.0 + C++ language
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
2 3 4 5 6 7
Top | Discussion index | About this forum | D home