On Sunday, 26 November 2017 at 18:58:04 UTC, jmh530 wrote:
> On Sunday, 26 November 2017 at 08:49:42 UTC, Dmitry Olshansky wrote:
>>
>> If all of the code is 100% @safe (not system and not trusted) you have a different language where write barriers would be cheaper to implement.
>>
>> Sadly you can’t “skip” write barriers in your @system code because it may run as part of larger @safe. Which is where they are the most costly.
>
> I was thinking you would use a generational or precise GC for @safe code and then fall back to the normal GC with @system/@trusted code.

Wishful thinking. Memory flows through a program and things allocated in @safe get passed to @system (including the last reference cases) and vise versa.

Also in D generational hypothesis may not bear as much value due to stack-allocation, libc heap allocations for temporaries likely via RAII. Not to mention cheap (thread-local) Ref Counting, C++ and many other language have to use atomics which makes RC costly.

Basically the GC heap is not all of the heap, so a young objects is even smaller part of that.

Lastly it is telling that new low-latency concurrent GCs do away without explicit generations.

I’m thinking a more efficient way to takle temporaries would be to add Regions to GC.
So the moment you enter a region all GC things are allocated in a special segment, once you leave it free the segment. The last trick is to tweak memory protection as guard pages over it. Boom! Now if somebody touches it - DanglingPointerException :)

Not a panacea but:
- libraries using too much of GC can be controlled (unless they build global state)
- manual memory management without memory corruption
- fast bump allocation, which is what all of sensible VM languages do

And no need to create entire separate heap with its own generational schema.

> Not sure if that's possible or not, but in my head it would be a separate heap from the @safe code.

And then I do append in @system on array allocated in @safe. Boom!

> Certainly would be added complexity.

On Monday, 27 November 2017 at 05:47:49 UTC, Dmitry Olshansky wrote:
> likely via RAII. Not to mention cheap (thread-local) Ref Counting, C++ and many other language have to use atomics which makes RC costly.

No, you dont. Nobody in their right mind would do so in C++ as a general solution. Seems there is trend in doing D-advocacy based on the assumption that programmers using other languages are crazy these days.

In C++ sync is manual, which is the only efficient way to do it. Proving correctness for an efficient general solution is an unsolved theoretical problem. You can do it for high level mechanisms, but not low level atm.

Rust and Pony claims to have solutions, but they are not general. D most certainly does not have it and never will.

When threading is a libray type then you cannot achieve more in D than you can achieve in C++, i.e. Shared is not going to do more than a C++ library type with a separate static analysis tool.

On Monday, 27 November 2017 at 06:36:27 UTC, Ola Fosheim Grostad wrote:
> On Monday, 27 November 2017 at 05:47:49 UTC, Dmitry Olshansky wrote:
>> likely via RAII. Not to mention cheap (thread-local) Ref Counting, C++ and many other language have to use atomics which makes RC costly.
>
> No, you dont. Nobody in their right mind would do so in C++ as a general solution. Seems there is trend in doing D-advocacy based on the assumption that programmers using other languages are crazy these days.

Last time I check shared_ptr can be safely shared across threads, hence RC is takling synchronization and most likely atomics since locks won’t be any better.

>
> In C++ sync is manual, which is the only efficient way to do

??? shared_ptr is nowhere manual.

Sorry but the rest of the of post is take a direction into the fog, that I don’t want to follow.

My post is about particular primitive in C++ std, what could be done instead or in addition to is not important.

On Monday, 27 November 2017 at 06:36:27 UTC, Ola Fosheim Grostad wrote:
> On Monday, 27 November 2017 at 05:47:49 UTC, Dmitry Olshansky wrote:
>> likely via RAII. Not to mention cheap (thread-local) Ref Counting, C++ and many other language have to use atomics which makes RC costly.
>
> No, you dont. Nobody in their right mind would do so in C++ as a general solution. Seems there is trend in doing D-advocacy based on the assumption that programmers using other languages are crazy these days.
>
> In C++ sync is manual, which is the only efficient way to do it. Proving correctness for an efficient general solution is an unsolved theoretical problem. You can do it for high level mechanisms, but not low level atm.
>
> Rust and Pony claims to have solutions, but they are not general. D most certainly does not have it and never will.
>
> When threading is a libray type then you cannot achieve more in D than you can achieve in C++, i.e. Shared is not going to do more than a C++ library type with a separate static analysis tool.

What I think Dmitry meant is that shared_ptr<T> uses atomic instructions for the reference counting (though you need to use atomic_shared_ptr, or atomic_* function if you want to modify the shared_ptr itself) and you can't opt out of that even if you're not sharing the shared_ptr with other threads. On the other hand in D, a properly designed SharedPtr(T) will use atomic instructions for reference counting, only if it's payload type T is has the 'shared' type qualifier. And if you have 'shared(SharedPtr(T))', only then you'll have atomic instructions for the SharedPtr struct itself, but unlike shared_ptr<T>, you won't have access to the non-thread safe methods.

On Monday, 27 November 2017 at 06:47:00 UTC, Dmitry Olshansky wrote:
> Last time I check shared_ptr can be safely shared across threads, hence RC is takling synchronization and most likely atomics since locks won’t be any better.

The controlblock can, but it is crazy to use shared_ptr for anything more than high level ownership. It is a general solution with weak pointers and extra indirection, not a typical RC implementation for datastructures.

>> In C++ sync is manual, which is the only efficient way to do
>
> ??? shared_ptr is nowhere manual.

There is an upcoming atomic_shared_ptr, but it is not in the standard yet.

> My post is about particular primitive in C++ std, what could be done instead or in addition to is not important.

Oh, but it is.

1. D currently does not provide what you says it does.

2. Sane C++ programmers rarely use shared_ptr for more than exchsnging ownership (suitable for sharing things like bitmap textures). There are plenty of other RC implementations for tracking memory. So you compare apples and oranges.

On Monday, 27 November 2017 at 06:59:30 UTC, Petar Kirov [ZombineDev] wrote:
> the shared_ptr itself) and you can't opt out of that even if you're not sharing the shared_ptr with other threads.

Well, the compiler can in theory ellide atomics if it csn prove that the memory cannot be accessed by another thread.

But it kinda is missing the point that if it only is in a single thread then it would typically only have only one assignment. Shared_ptr is for holding a resource not for using it...

On Monday, 27 November 2017 at 07:09:25 UTC, Ola Fosheim Grostad wrote:
> But it kinda is missing the point that if it only is in a single thread then it would typically only have only one assignment. Shared_ptr is for holding a resource not for using it...

Just to expand a bit on this: What is lost here is that what has been proposed for D is to have a RC solution to solve what Rust does with borrowed pointers. Not unlike Swift.

In C++ life time management of borrowed pointers is fully manual, so it relies on algorithmic design rather than a programming mechanism. Although for C++ there is upcoming wrapper-types to allow for separate static analysis tooling that is comparable to Rust.

The intended usage is not comparable. (In C++ you typically will have per-type or per-application RC, wrapped up where you need it by encapsulation and move-semantics.)

Please stop this flame and make first real step into bringing precise GC to us.
Current GC in D is shit and all this speaking won't improve situation.
The PR is not merged although it passed all the tests.

On Monday, 27 November 2017 at 09:38:52 UTC, Temtaime wrote:
> Please stop this flame

There is no flaming.

> Current GC in D is shit and all this speaking won't improve situation.

If so, why are you here? But you are fundamentally wrong. Precise GC will not bring a general improvement, for that you need advanced pointer analysis. So you need a change of philosophy to get a performant GC: semantic changes.

On Monday, 27 November 2017 at 09:38:52 UTC, Temtaime wrote:
>
> Current GC in D is shit

Can you elaborate?

"D is totally useless"..."Dlang is a toy in outer space"... "GC in D is shit" ..

I'm very open minded to these different argument styles, and occassionaly make use of them myself. But in a discussion about GC, some technical details might prove to be very useful to those of us following this discussion.

I encourage you to further refine your argument...  ;-)

https://en.wikipedia.org/wiki/Argument