21–30 of 196 posts
Twitter makes no sense as platform for long reads. The format is atrocious and difficult to follow. (When all that you have is a hammer all problems seem a nail)
Finally I see somebody mentioning the memory ordering. I've been wondering for a while how they've managed to get multithreaded x86 emulation working fast. I had heard mentions of "kernel support", but hadn't really looked into it much. It turns out that what I had guessed was correct, and that they simply added intel's memory ordering as an optional mode to their processor; "When running translated x86 code, they sw…
RISC-V also has a weak memory ordering by default, with TSO (like x86) as an optional feature. So this is not a novel approach in any way.
Earlier quoted context omitted.
It’s much more than twice as fast. https://twitter.com/catfish_man/status/1326238434235568128?s...
What's the actual optimization though?
"Weaker memory model makes acquire-release atomics possible to implement much more efficiently, in exchange for not hiding some classes of multithreading bugs"
Also, AFAIK MS translation of x86 -> ARM works different than Rosetta2, so the results aren't just because "Apple added Intel's memory ordering to their CPU" (whatever that means)
More readable format https://threadreaderapp.com/thread/1331735383193903104.html
>8/ Another "magic" trick is how their "Swift" programming language uses "reference counting" instead of the "garbage collection" in Android. They did something in their CPU to double the speed of reference counting. 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 / cmpxch…
> 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).
>8/ Another "magic" trick is how their "Swift" programming language uses "reference counting" instead of the "garbage collection" in Android. They did something in their CPU to double the speed of reference counting. 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 / cmpxch…
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