On Thursday, 20 May 2021 at 16:33:09 UTC, IGotD- wrote:

How does Nim deal with references to array elements and struct fields? Does it use fat pointers?

On Thursday, 20 May 2021 at 17:52:11 UTC, Ola Fosheim Grostad wrote:

Yes, Nim has fat pointers denoted by the "ref" keyword which means that it is GC allocated.

https://nim-lang.org/docs/manual.html

References (similar to pointers in other programming languages) are a way to introduce many-to-one relationships. This means different references can point to and modify the same location in memory (also called aliasing).

Nim distinguishes between traced and untraced references. Untraced references are also called pointers. Traced references point to objects of a garbage-collected heap, untraced references point to manually allocated objects or objects somewhere else in memory. Thus untraced references are unsafe. However, for certain low-level operations (accessing the hardware) untraced references are unavoidable.

Traced references are declared with the ref keyword, untraced references are declared with the ptr keyword. In general, a ptr T is implicitly convertible to the pointer type.

On Thursday, 20 May 2021 at 16:33:09 UTC, IGotD- wrote:

Looking forward to the Nim RC beating these benchmarks.

https://devblogs.microsoft.com/aspnet/grpc-performance-improvements-in-net-5/

https://www.techempower.com/benchmarks/

And it isn't as if Nim has a community that much greater than D currently has.

Rust doesn't have RC, just library types, Arc/RC everywhere is just as slow as shared_ptr everywhere.

In fact, the way that Apple got around improving ARC wasn't spending more development resources on their Objective-C/Swift compilers, rather develop a complete new CPU.

Now iDevices have turned into Swift/Objective-C machines.

https://blog.metaobject.com/2020/11/m1-memory-and-performance.html

On Thursday, 20 May 2021 at 18:18:40 UTC, Paulo Pinto wrote:

@system code does not have to be @safe. Next step would be to add borrowing selectively. You can also use borrowcounters during testing, no need to go for static borrowing, actually.

D only needs atomics for shared, not comparable, as an Apple engineer kindly has pointed out in this forum some years ago. He did no discourage D from pursuing ARC, on the contrary.

On Thursday, 20 May 2021 at 18:35:58 UTC, Ola Fosheim Grostad wrote:

As you can see Obj-C had some extra challenges because of compatibility with manual RC:

http://forum.dlang.org/post/hgmhgirfervrsvcghchw@forum.dlang.org

On Thursday, 20 May 2021 at 18:18:40 UTC, Paulo Pinto wrote:

Benchmarks can usually be tweaked to produce the outcome you're after. I usually get better latency and memory consumption and worse throughput with "Nim RC". However, the Nim compiler itself is over 100K lines of code and 22% faster when compiled with "Nim RC", so in this case the throughput is better. That particular result might be machine specific though as I tested it on an M1 indeed. :-)

The fact that the RC algorithm is oblivious to the involved heap sizes and to the amount of alive data makes it a nice default though -- works well when you use much memory or when you have little heap sizes.

But Nim actually bets on RC because it's much more amenable to manual optimizations and because it works well with custom memory management, making it a good fit for "systems programming".

On Thursday, 20 May 2021 at 21:09:22 UTC, Araq wrote:

How much better do you feel Nim could get at getting rid of inc/dec pairs compared to where you are now?

On Thursday, 20 May 2021 at 22:52:35 UTC, Ola Fosheim Grøstad wrote:

Not much -- we implemented all worthwhile optimizations. And given the right annotations (sink, lent, move) there are no superfluous inc/dec pairs left.

We're at the point where tweaking the inliner further makes more sense then focussing on inc/dec pairs.

On Thursday, 20 May 2021 at 19:11:56 UTC, Ola Fosheim Grostad wrote:

I guess everyone over here will keep talking in circles about memory management.

Meanwhile TinyGo, CircuitPyhton, Meadow, Astrobe, MakeCode. microEJ just keep increasing their market share, while D keeps its soul search for the golden solution to replace GC.

On Friday, 21 May 2021 at 07:07:19 UTC, Paulo Pinto wrote:

What do you propose that D should do?

I am not in a position to do anything more than propose ideas that can be developed into something that both satisfies the high level D programmers and the low level programmers and try to build some common ground. Building common ground takes time and repeated communication. You need to consider many proposals and evolve them to get to a good solution.

Nim seems to have considered and tested several options before landing on ARC, that is the right approach. Don't settle for anything before you have explored the options.

In my opinion a task based GC + shared RC should satisfy the needs of both groups and most single threaded code would not need many changes.