On Monday, 21 September 2015 at 18:28:19 UTC, jmh530 wrote:
> My understanding is that the key benefit of Rust's system is that compile time checks don't have the runtime costs of smart pointers.

+ aliasing information.

If the compiler can prove that two pointers point to non-overlapping memory regions then the compiler can optimize better. This is one of the reasons why Fortran compilers managed to do better than C for a long time.

On Monday, 21 September 2015 at 19:32:23 UTC, Ola Fosheim Grøstad wrote:
>
> If the compiler can prove that two pointers point to non-overlapping memory regions then the compiler can optimize better. This is one of the reasons why Fortran compilers managed to do better than C for a long time.

Interesting. Not to resurrect the older D vs. Rust thread, but I have heard it that it can be painful to do some things in Rust. D often has the ability to do unsafe things, like disable the GC. I was looking at how Rust has raw pointers and smart pointers. I'm curious as to what it is missing that is making things more difficult for people. If you or anyone has any idea.

On Tuesday, 22 September 2015 at 02:15:51 UTC, jmh530 wrote:
> Interesting. Not to resurrect the older D vs. Rust thread, but I have heard it that it can be painful to do some things in Rust. D often has the ability to do unsafe things, like disable the GC. I was looking at how Rust has raw pointers and smart pointers. I'm curious as to what it is missing that is making things more difficult for people. If you or anyone has any idea.

My knowledge of Rust is only cursory, but if you want to graphs (like a doubly linked list) you have to use a different pointer type. Just like in c++ where you have to use shared_ptr (+ weak_ptr or raw pointers) and not unique_ptr. You sometimes also have to explicitly state relationships between lifetimes (that one object outlives another).

On Tuesday, 22 September 2015 at 03:59:31 UTC, Ola Fosheim Grostad wrote:
> On Tuesday, 22 September 2015 at 02:15:51 UTC, jmh530 wrote:
>> Interesting. Not to resurrect the older D vs. Rust thread, but I have heard it that it can be painful to do some things in Rust. D often has the ability to do unsafe things, like disable the GC. I was looking at how Rust has raw pointers and smart pointers. I'm curious as to what it is missing that is making things more difficult for people. If you or anyone has any idea.
>
> My knowledge of Rust is only cursory, but if you want to graphs (like a doubly linked list) you have to use a different pointer type. Just like in c++ where you have to use shared_ptr (+ weak_ptr or raw pointers) and not unique_ptr. You sometimes also have to explicitly state relationships between lifetimes (that one object outlives another).

But that's very annoying to work with and more pain than gain.

In my initial post I was thinking of a runtime solution where the object knows it's own life cycle, or at least knows when its own death is nigh and destroys itself. I don't know if this is possible at all, I simply borrowed this idea from biology. We don't have GC in our bodies, cells know when it's time for them to go.

Am Mon, 21 Sep 2015 19:32:21 +0000
schrieb Ola Fosheim Grøstad <ola.fosheim.grostad+dlang@gmail.com>:

> On Monday, 21 September 2015 at 18:28:19 UTC, jmh530 wrote:
> > My understanding is that the key benefit of Rust's system is that compile time checks don't have the runtime costs of smart pointers.
> 
> + aliasing information.
> 
> If the compiler can prove that two pointers point to non-overlapping memory regions then the compiler can optimize better. This is one of the reasons why Fortran compilers managed to do better than C for a long time.
> 

Unfortunately we have even weaker optimizations than C regarding aliasing information. There's code in druntime and phobos which breaks C aliasing rules (usually pointer type casts) and this caused real issues on ARM systems with GDC. As the D spec doesn't state anything about aliasing we simply disable strict aliasing rules. I guess there's also lots of D user code which isn't compatible with strict aliasing rules.

On Tuesday, 22 September 2015 at 09:01:07 UTC, Chris wrote:
> But that's very annoying to work with and more pain than gain.

I don't know... unique_ptr in C++ is quite ok for managing resources, but it does not track "borrowed pointers". But as I point out one can:

1. do it in runtime in debug builds (have a pointer back to the owning pointer and "assert(*this.owner==this.ptr)" at every dereference).

2. one can build a prover that does a fair job out of proving that the owner lives longer than any pointer copied from the owner.

The caveat is that 2 might either require explicit annotations and/or take a long time, but maybe it is ok that it takes a long time if you only do pointer sanitisation (2) once in a while and use the assert method (1) during the daily development?

> In my initial post I was thinking of a runtime solution where the object knows it's own life cycle, or at least knows when its own death is nigh and destroys itself. I don't know if this is possible at all, I simply borrowed this idea from biology. We don't have GC in our bodies, cells know when it's time for them to go.

Yes, that would be C++ shared_ptr and weak_ptr. Then you have to explicitly break all cycles in the graph with weak_ptr. All pointers pointing backwards in the three of shared_ptrs have to be weak_ptrs.

Kind of expensive since you need two objects for every object. When all shared pointers are dead you free the object, but you need a reference object to reference count weak_ptrs.

IIRC (I don't use shared_ptrs much).

On 09/18/2015 09:26 PM, Rory wrote:
> The new GC in Go 1.5 seems interesting. What they say about is certainly interesting.
> 
> http://blog.golang.org/go15gc
> 
> "To create a garbage collector for the next decade, we turned to an algorithm from decades ago. Go's new garbage collector is a concurrent, tri-color, mark-sweep collector, an idea first proposed by Dijkstra in 1978."

A concurrent collector for sure reduces latency but lowers the
throughput and also steals memory bandwidth from your program.
It also requires write-barriers and we decided against them b/c they
slow down every program by ~5%. Though it might be somehow possible to
make them optional only for the people using a concurrent GC.

The key to a low latency/high throughput GC is being able to incrementally collect the heap. There is a very interesting paper that uses the type system to perform incremental collections.

http://forum.dlang.org/post/mcqr3s$cmf$1@digitalmars.com

On Thursday, 24 September 2015 at 00:08:18 UTC, Martin Nowak wrote:
> The key to a low latency/high throughput GC is being able to incrementally collect the heap. There is a very interesting paper that uses the type system to perform incremental collections.
>
> http://forum.dlang.org/post/mcqr3s$cmf$1@digitalmars.com

I haven't read the paper, but how does this solve collecting things like strings, or other "leaf types" when you use separate compilation units?

The easy thing to do is to use GC locally (like for a fiber) and use move semantics for moving objects from one locality to the other (between fibers).

This is also compatible with next gen computing where CPUs have local memory. Incidentally this is also the multithreaded model used in web browsers...

On 09/24/2015 03:49 AM, Ola Fosheim Grøstad wrote:
> On Thursday, 24 September 2015 at 00:08:18 UTC, Martin Nowak wrote:
>> The key to a low latency/high throughput GC is being able to incrementally collect the heap. There is a very interesting paper that uses the type system to perform incremental collections.
>>
>> http://forum.dlang.org/post/mcqr3s$cmf$1@digitalmars.com
> 
> I haven't read the paper, but how does this solve collecting things like strings, or other "leaf types" when you use separate compilation units?

We'd use runtime typeinfo.

> The easy thing to do is to use GC locally (like for a fiber) and use
> move semantics for moving objects from one locality to the other
> (between fibers).

Though it's challenging to efficiently manage all the GC structures for a small scope. Doing this per thread is a proven technology (see https://trello.com/c/K7HrSnwo/28-thread-cache-for-gc).

On Sunday, 27 September 2015 at 16:54:52 UTC, Martin Nowak wrote:
> On 09/24/2015 03:49 AM, Ola Fosheim Grøstad wrote:
>> I haven't read the paper, but how does this solve collecting things like strings, or other "leaf types" when you use separate compilation units?
>
> We'd use runtime typeinfo.

But doesn't that imply a full scan when you are scanning for common types that live on leaf nodes in the graph?

>> The easy thing to do is to use GC locally (like for a fiber) and use
>> move semantics for moving objects from one locality to the other
>> (between fibers).
>
> Though it's challenging to efficiently manage all the GC structures for a small scope. Doing this per thread is a proven technology (see https://trello.com/c/K7HrSnwo/28-thread-cache-for-gc).

That's a good start, but hardware threads range from 1-32 threads on current CPUs, so it is likely to affect modelling more than doing it on an actor/fiber level. If you could group N actors on a single GC heap you could run a simulation across many threads and then collect inbetween.

Btw, C++ appears to get the semi-stackless co-routines (no state on stack when yielding), which also appears to be the model used in Pony-lang. D really should consider a move in that direction combined with it's GC strategy.