fun fact: retaining and releasing an NSObject takes ~30 nanoseconds on current gen Intel, and ~6.5 nanoseconds on an M1
...
Weaker memory model makes acquire-release atomics possible to implement much more efficiently, in exchange for not hiding some classes of multithreading bugs
That's the part I'd love someone knowledgeable to explain.
> double the speed of reference counting
The simplest low latency system memory making atomics faster in some contexts (faster cache write back/fetch).
Then atomic operations (using Aquire/Release) are theoretically faster on ARM due to the weak memory ordering (I'm not sure if this does help for translated x86 code).
Potentially other reasons can include:
- maybe optimized fetch add/sub instructions (or more precise the ARM instructions used by fetch add/sub functions in higher level languages)
- maybe tweaks to the coherence protocol
- maybe specialized optimizations in the pipelineing
All in all it means Apple focused on making sure fetch add/sub are fast (most likely as this is what is normally used for Rc).
It is possible because if you don’t have TSO(total store order), you can employ atomic operations without waiting/flushing previous items in the CPU’s store buffer
What the hell does that even mean ?
Disregarding the nonsensical attribution of magic to Swift vs Java, if "reference counting" on translated x86 code is faster, then I suppose M1 does "lock add / cmpxchng" or whatever faster than X86.
I would love to know how. Other than just as a side-effect of a SoC, UMA architecture.