The presumption is that your `JsonNode` is concrete in both worlds. It is a
generic in my world. In my proposition all ref objects would be a generic that
can be either an atomic or not. So the compiler does need to do anything but
instantiate the type/procs when used. As `{.atomic.}: JsonNode` (whatever the
syntax decided I am still partial to `JsonNode[Atomic = true]` ) and `JsonNode`
are two different types `JsonNode` would become a typeclass for both atomic and
non-atomic(we'd just always instantiate the non-atomic in places we'd have a
concrete procedure). This just means normal generic rules apply so there is no
issue of all `JsonNode` s being non atomic and now needing to be atomic.
> As for the thread-safety argument, if there is no cost, what is the basis of
> your concern?
The concern is that there is a cost and platform support.
Symbiolic's M1: 4.2% slowdown
Your 5600x: 0.73% slowdown(though still nearly twice as slow as mine. I
compiled it in ~4.6s vs. ~4.9s Get your OS/Ram/Cooling fixed)
My 5600x: 6.4% slowdown
sky_khan's 6700k: 14% slow down
Juan: 1.6% speed up
Ringabout: 11% slow down
Araq's Ryzen: 1.5% slow down
Araq's M1: 5.1% slow down
Jmgomez's Threadripper: 9.9% slowdown
Jmgomez's M1Max: 0.2% faster
If these statistics are not just poor measuring scenarios getting rid of
non-atomic Arc can cost some CPUs 10% of performance. This does not include
embedded cpus or any other swanky CPU(llvm-mos presently works with Nim
generated code). My completely biased and unsubstantiated wager is that you'd
see older and less multi-thread CPUs taking the brunt of this slowdown, which
also happens to the exact CPUs that need the performance.
