On Wednesday, 19 May 2021 at 11:58:21 UTC, josh wrote:

There is an ideology in @safe, but the problem is that pointer analysis is a research topic, so pursuing it in @nogc code is not realistic... Goals are set too high.

Lower the goal to having a library RC pointer with ARC and suddenly you are in a better position than C++ for some use cases.

By pursuing @safe in non-gc code it will either take forever or you'll end up with something too annoying to use.

On Thursday, 20 May 2021 at 08:31:47 UTC, Ola Fosheim Grostad wrote:

Doesn't D already have that?

https://dlang.org/library/std/typecons/ref_counted.html

Also when you mention ARC, is that atomic reference counting or automatic reference counting?

Yes, @safe and non-gc/any-gc goals should be separated.

On Thursday, 20 May 2021 at 11:10:25 UTC, IGotD- wrote:

I mean removing inc/dec by static analysis. Possibly also turning shared_ptr into unique_ptr where possible, which is tricky because of sizeof. I guess I dont mean library RC, but something close to it. It could look like a template.

Done in a way that could later be extended to the heap, so if you can prove that something is used as a stack, you can get rid of the refcount...

On Thursday, 20 May 2021 at 12:59:48 UTC, Ola Fosheim Grostad wrote:

Well, actually, if you accept one indirection then they would have the same sizeof, but it would be slow.

On Thursday, 20 May 2021 at 12:59:48 UTC, Ola Fosheim Grostad wrote:

Why not go further and turn GC pointer to RC if acyclicity is given, and if possible turn it into an owned pointer?

On Thursday, 20 May 2021 at 14:58:36 UTC, sighoya wrote:

There is no GC pointer, only raw pointers?

On Thursday, 20 May 2021 at 12:59:48 UTC, Ola Fosheim Grostad wrote:

Contrary to popular belief ARC implementations are quite lousy.

Good in theory, not so much when placed in benchmarks, but I guess Apple's marketing helps selling the pivot regarding Objective-C GC failure.

https://github.com/ixy-languages/ixy-languages

To the point that in all these years Microsoft never bothered to try that in any of their C++ COM/UWP aware implementations.

Also there isn't a single C++ compiler that does such optimizations to their smart pointer classes.

On Thursday, 20 May 2021 at 15:28:52 UTC, Paulo Pinto wrote:

If we can get rid of 40% that is pretty good. It is for ownership only, in performance code, raw pointers everywhere else.

Their IRs are low level and cannot do ARC well, LLVM lost too much context.

D can assume single threaded counters which makes a big difference.

What are the alternatives? D remains a hobby language forever, because it does not exceed some critical usage level, or you make all the required breaking changes and make a new start. I would choose the latter one ;-).

On Thursday, 20 May 2021 at 15:28:52 UTC, Paulo Pinto wrote:

Compared to what?

So a tracing GC is faster and as RAM increases what happens to the time spent scanning? Reference counting has a performance impact which is known. The reference counting in Nim has been a success a provided in general better performance than the tracing ones (something Nim can easily do as you can just swap them out). Because of the RC is now the default GC type in Nim. RC has also a known performance impact that is spread through out the execution. Loops can be optimized so that any inc/dec can be avoided.

Rust has interesting take on RC as move is the default. There is no inc/dec on a move and neither when borrowing (you borrow the inner type). It's kind of a natural optimization because of this. Because of this I would rather see a move by default by type in D.