On the always-thread-safe, and use of atomic-ARC aspects of Nimony

[niekbouman]

I found the blog post Nimony and the following sentence made we pause:

If you can run well on embedded systems you run well on everything else.

Modern large machines (with >64 or even more than 100 cores), with possibly serveral NUMA domains, can be quite far off from small "embedded systems", depending on your definition of the latter. I read that Nimony will do atomic-arc for memory management, and mix concurrency and parallelism via a single spawn construct. In large machines, contention, caused by locking, use of atomics and cache coherency traffic can be a major source of performance problems.

If I correctly understand the Nimony design, it seems to me that the current thread-safe-by-default and atomic-ARC design of Nimony will be a significant pessimization for this kind of highly parallel (many-core) machines.
E.g., for async, it would be nice to have the control to say that (most) tasks cannot switch the thread (assuming #threads = #cores) on which they were created, which would remove the need for using synchronization primitives (locks, atomics) in such tasks. Numa-friendliness when allocating/using memory is another topic that becomes hard if you cannot control where tasks run.

My question is whether this was a deliberate design choice, and whether the concurrency/parallelism design of Nimony is already set in stone, or if is there still room for design discussion on this topic.

[Araq]

Nothing is set in stone, I merely describe my vision in this document. That said, I'm quite optimistic wrt atomic reference counting as I have evolved my "cursor optimizer" (it exists in Nim 2 too) and it can elide many RC ops that the move semantics miss.

[AmjadHD]

Will nimony not use atomic RC for single-threaded programs?

[Araq]

That's very simple to do (PRs accepted!) but it's not nearly as important as we strive to optimize the RC ops away regardless of whether they use atomics or not.