Finally a company has the guts to move us from the straitjacket of x86. I hope this is just the beginning of much needed innovation in CPU architecture. Due to the MS/Intel duopoly we had to suffer x86 for decades with few real options.
Apple CPU tricks: memory reordering, JavaScript support, ref counting
41–50 of 196 posts
Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting
#42Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting
#43> 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).…
the bait is that reference counting is (often considered to be) a type of garbage collection, and that correction is frequently made in comment threads
and hey, here we are
Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting
#44> 4/ So Apple simply cheated. They added Intel's memory-ordering to their CPU. When running translated x86 code, they switch the mode of the CPU to conform to Intel's memory ordering.
Uh, no. Implementing TSO in a highly performant way is not "cheating", it's a difficult engineering feat. And no, TSO is not some fancy Intel thingy. It's a standard memory model.
Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting
#45> 4/ So Apple simply cheated. They added Intel's memory-ordering to their CPU. When running translated x86 code, they switch the mode of the CPU to conform to Intel's memory ordering. Uh, no. Implementing TSO in a highly performant way is not "cheating", it's a difficult engineering feat. And no, TSO is not some fancy Intel thingy. It's a standard memory model.
i believe in this case cheating is being used to mean that they were clever, working around the problem, not doing anything wrong
Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting
#46>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
I guess I understand the ARM behavior, but both this thread and the original one talk about x86 retain/release being faster on M1 as well.
That's the part I'd love someone knowledgeable to explain.
Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting
#47Earlier quoted context omitted.
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.
If you read the Catfish_Man tweet, he says that even under rosetta refcounting is faster, and under rosetta M1 has TSO.
Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting
#48Re: “JavaScript” instructions. I think it means FJCVTZS which is not Apple specific and only yields a fairly minor improvement. It’s not even really that JS specific, it’s definitely designed to help with JS numbers but it’s not like a large chunk of JS functionality is in silicon.
The memory ordering stuff is cool, calling it cheating might be a bit harsh although it would be cool if other ARM cores would support something like this.
Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting
#49Earlier quoted context omitted.
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.
Well sure, POWER7 implemented a strong-ordering mode specifically for x86 emulation a decade ago [1] [1] https://marc.info/?l=linux-mm&m=121382852909406&w=2
Thanks, I have been looking for this for ages and I couldn't find a reference. I was starting to think I immagined it.
Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting
#50Earlier quoted context omitted.
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
FWIW, the name is HEVC or H.265. AVC is H.264.