Article about problems & suggestions for D 2.0

[Benjamin Thaut]

Am 30.08.2011 08:00, schrieb Andrei Alexandrescu:
> On 8/30/11 12:45 AM, Benjamin Thaut wrote:
>> Am 30.08.2011 02:56, schrieb Andrei Alexandrescu:
>>> On 8/29/11 4:36 PM, Walter Bright wrote:
>>>> On 8/29/2011 2:22 PM, Jonathan M Davis wrote:
>>>>> Certainly, for the common case, adding move constructors is a needless
>>>>> complication, and I'd _very_ leery of the ramifications of the
>>>>> compiler not
>>>>> being able to rely on a move having the bits stay absolutely identical
>>>>> (and a
>>>>> move constructor would make it possible for the struct's state to
>>>>> change
>>>>> completely instead of really being a move). It's not necessarily
>>>>> completely
>>>>> unreasonable, but you appear to have found what I would expect to be a
>>>>> _very_
>>>>> abnormal use-case.
>>>>
>>>> Andrei and I have talked about adding move constructors, but I agree
>>>> with you that it really seems to be a tar pit we'd really like to
>>>> avoid.
>>>> C++ has a lot of subtle problems caused by supporting this, not the
>>>> least of which is efficiency problems.
>>>
>>> The language semantics make move construction unnecessary. Values are
>>> moveable as bits through memory.
>>>
>>> I think the article is a bit confused on this particular matter. Only
>>> objects with value semantics are freely moveable, so they have no direct
>>> interaction with the garbage collector. What they might want to do is to
>>> hold a pointer/reference _inside_ of them and deregister that pointer
>>> with the garbage collector with the destructor. Due to the indirection,
>>> it doesn't matter where the object is in memory.
>>>
>>>
>>> Andrei
>>
>> I don't see implementing a GC as that of a abnormal use case.
>
> Implementing a GC is an exceedingly rare privilege.
>
>> Especially
>> given the fact that D is a garbage collected language and could benefit
>> a lot from features that make implementing a GC easier.
>
> I don't believe D should be in the business of adding features that make
> implementing a GC easier. Such a task is extremely specialized; if the
> language allows it, that's about enough.
>
>> In thise special
>> case the discussed struct would be a wrapper for every reference on the
>> stack, so the references can be tracked by the GC and changed if
>> neccessary. Adding a level of indirection to every reference would
>> greatly impact performance because it would most likely add yet another
>> cache miss when accessing a reference. I'm very well aware of D's
>> concept of structs. But sometimes this concept is very bad for
>> performance, that is what I wanted to point out. Adding a move
>> constructor which most of the structs won't even use, should be less of
>> a performance impact, then adding another level of indirection.
>
> Clearly adding an extra level of indirection would be harmful, no two
> ways about it. But essentially the object model is what it is: there are
> value types that move, and there are reference types that don't. Deal
> with it. If you need to implement a garbage collector, you can't do it
> with move hooks because they're not provided. In a subtle way it's a
> given, although I totally understand how this or that hook would make
> your work easier. I don't find the complaint valid at all.
>
>
> Andrei

My problem currenlty mostly is, that the current GC takes way more time 
then the usual 5% slowdown that gets mentioned with most GCs. Thats why 
I would prefer adding features that would make implementing GCs
a) easier
b) would actually allow do implement a GC that is not a Mark & Sweep
c) faster because they won't have to scan all memory searching for a pointer

Currently there is no way to track the references or pointers on the 
stack because the language does not include such a feature, nor can it 
be build with any of the language provided mechanisms.

But maybe its just my point of view on this. In the field I'm mostly 
active in (3d games) performance is everything. Especially on the 
consoles. Most programmers even sacrifice most c++ features on the 
consoles (exceptions, RTTI, virtual functions to some extend) just to 
get more performance out of their game.
-- 
Kind Regards
Benjamin Thaut