More readable format
Apple CPU tricks: memory reordering, JavaScript support, ref counting
11–20 of 196 posts
Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting
#12Is the ARM ISA fundamentally faster than x86? If the underlying architectures are converging as described, it kinda seems that the difference between the two instruction sets are more legal than technical.
Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting
#13>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 / cmpxchng" or whatever faster than X86.
I would love to know how. Other than just as a side-effect of a SoC, UMA architecture.
Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting
#14"They did something in their CPU to double the speed of reference counting." I wish we'd get that on x86_64 too. Especially since it seems like an obvious and easy win.
For an the references to this, I haven't yet seen a description of what the optimization is. Anyone know?
It’s much more than twice as fast.
https://twitter.com/catfish_man/status/1326238434235568128?s...
Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting
#15Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting
#16Finally 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.
There's a spec for that, but I don't know of any synthesizable RV cores with optional TSO that have actually been made, whether ASICs _or_ configurable logic.
That does make it pretty novel on Apple's end. I agree with Heinlein that "a good idea is worth one bottle of scotch"; that the execution is where the vast majority of the work is and where the vast majority of praise should lie.
And that's coming from someone who's not as bullish as some on Apple's execution. I think AMD's cores are better and compared 1/1 on the same process node Apple would look a little behind overall. But Apple for sure gets praise for their execution here (optionality in store order), which is remarkably good.
Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting
#17"They did something in their CPU to double the speed of reference counting." I wish we'd get that on x86_64 too. Especially since it seems like an obvious and easy win.
For an the references to this, I haven't yet seen a description of what the optimization is. Anyone know?
I think I found the answer in this tweet.
https://twitter.com/Catfish_Man/status/1326298205034696705
Heres a snipped quote.
"this further improvement is because uncontended acquire-release atomics are about the same speed as regular load/store on A14"
Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting
#18Is the ARM ISA fundamentally faster than x86? If the underlying architectures are converging as described, it kinda seems that the difference between the two instruction sets are more legal than technical.
No, just a lot of brute force and focused optimization going on the M1. There are a few advantages, (it’s a newer architecture after all) but nothing that justifies the current difference.
Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting
#19> reference counting is faster than garbage collection
lol, not taking the bait