Apple CPU tricks: memory reordering, JavaScript support, ref counting • Hacker News Board

Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting

#31

Post by ksherlock » Sat, Nov 28, 2020, 1:29 AM UTC

muststopmyths wrote: post #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 / cmpxch…

Maybe this: https://twitter.com/Catfish_Man/status/1326238434235568128

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

Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting

#32

Post by phs318u » Sat, Nov 28, 2020, 1:35 AM UTC

dmart wrote: post #5

Hokusai wrote: post #3

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)

This was a legitimate criticism back when there was no way to thread tweets and you had to read them in reverse. Now that you just scroll down like any other website, it just sounds like tired complaining.

This complaint is about more than mere website formatting (per HN guidelines). There's now 11 distinct reply threads of fragmented discussion to dig into, for anyone that might be interested. Hokusai is right to complain about this. And people savvy enough to write the article should know better. Post it on a blog and tweet the link. How hard is that?

Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting

#33

Post by dathinab » Sat, Nov 28, 2020, 1:42 AM UTC

voldacar wrote: post #19

> reference counting is faster than garbage collection lol, not taking the bait

But reference counting is (potentially) faster then garbage collection. At least under some circumstances:

- modern architecture having fast atomic fetch_add/sub

- weak memory ordering making atomic fetch_add/sub even faster (if Acquire/Release ordering is used)

- optimize the usage of reference counting by eliminating pointless reference counting, e.g. as done by Objective-C/Swift automatic reference counting (ARC). Or e.g. done when using borrows in rust for everything except the places you know you really need to clone the Atomic Reference Counter (also ARC but a different one ;=) ).

Reference counting was for a long time basically guaranteed to be slower then garbage collection because of slower atomics, no weak memory ordering and "naive" usage of reference counting introducing a lot of unnecessary reference counter increased and decreases.

But with modern hardware and compilers it's no longer as clear cut, at least in practice wrt. to modern hardware.

Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting

#34

Post by tjalfi » Sat, Nov 28, 2020, 1:45 AM UTC

danvk wrote: post #22

Can someone say more about the JavaScript optimization?

They might be referring to the ARM FJCVTZS instruction[0].

It speeds up converting JavaScript doubles to 32-bit integers.

[1] is the Webkit commit that added support for FJCVTZS, it was between a 0.5 to 2% speedup - that's a big win for a mature optimizer.

[0] https://stackoverflow.com/a/50966903/

[1] https://bugs.webkit.org/show_bug.cgi?id=184023#c24

Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting

#35

Post by annilt » Sat, Nov 28, 2020, 1:53 AM UTC

danvk wrote: post #22

Can someone say more about the JavaScript optimization?

In addition to FJCVTZS instruction, they added more floating point execution units and registers. Also did lower latency of pipelined fp instructions

Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting

#36

Post by wmf » Sat, Nov 28, 2020, 1:55 AM UTC

dukeofdoom wrote: post #23

They also seem to have added video codec decoders, because it can run 8k timelines pretty well in final cut. 4k without dropping frames even on the macbook air.

Every GPU including Nvidia, AMD, and Intel have video decoders.

Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting

#37

Post by barnaclejive » Sat, Nov 28, 2020, 1:59 AM UTC

apetrovic wrote: post #27

Is there any reference/confirmation for all of this? The fact that the author types "Swift" under quotes and doesn't know that refcount is something inherited from Objective C and the whole OS rely on it makes the rest of claims a bit more gossipy. 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 tha…

The author did type "Swift" but it applies to Obj-C also, obviously. I wouldn't discount the whole post because of that slip-up. The optimizations made to reference counting are more than "gossip". David Smith posted about this weeks ago also, if you need more reference/confirmation than that I'm not sure what to tell you.

Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting

#38

Post by dukeofdoom » Sat, Nov 28, 2020, 2:05 AM UTC

wmf wrote: post #36

dukeofdoom wrote: post #23

They also seem to have added video codec decoders, because it can run 8k timelines pretty well in final cut. 4k without dropping frames even on the macbook air.

Every GPU including Nvidia, AMD, and Intel have video decoders.

Yes, but I think the latest codec that canon uses in their newest cameras for 10 bit 8k raw are now supported. I'm not sure if it's hvac265 or something else

Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting

#39

Post by toast0 » Sat, Nov 28, 2020, 2:10 AM UTC

pythonvisa wrote: post #12

Is 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.

I think there's a couple things here. x86 defines a pretty strict ordering of memory operations, where ARM is more relaxed; as discussed elsewhere in the thread, this means atomic operations, used for synchronization, will need to wait for pending stores to finish on x86, but not on ARM.

The other thing is that the M1 processor seems to be a lot wider than contemporary processors. This means it can (potentially) do more operations per clock. Wider processors are harder to clock faster, but it works for Apple. Apple has no desire to put in the cooling you need to get chips running at 4+ GHz, so it's not a big deal if their chips are clock limited. On the other hand, Intel and AMD like their cores to approach 5 GHz at the top end.

Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting

#40

Post by annilt » Sat, Nov 28, 2020, 2:11 AM UTC

spankalee wrote: post #10

fxtentacle wrote: post #4

"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?

x86 has total store order, all stores are queued(store buffer) in the CPU and then pushed to the cache subsystem. Last item has to wait previous ones. Arm doesn’t have TSO, so CPU can reorder stores in the queue or issue stores out of order etc. depending on memory barrier use.