61–70 of 196 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
I believe with regards to TSO, it is actually a huge benefit performance wise. Without you would need to effectively have a barrier after every memory operation ARM, reducing performance drastically.
Implementing the memory ordering in hardware is a huge performance benefit, but they didn’t have to do it with a switch like they have right now. ARMv8.4-RCpc would be enough, and I believe M1 supports these too. (FWIW, Rosetta itself does “cheat”: the translated code and the runtime shares an address space, and memory accesses are not checked, so it’s possible to write an “Intel” binary that is aware of the runtime…
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.
It’s important to note that most of the things mentioned here are just “tricks”: they’re fun to discover and talk about, but they really only end up being minor wins in practice. TSO is great…if you are trying to make a simpler Rosetta (it’s not even necessary on the M1, although I think Apple is still using it for convenience; I’m still trying to find out where). The JavaScript instruction speeds up…one specific rou…
The JS rounding mode instruction wasn't even Apple's invention, it's standard ARMv8. But yes, Apple spends a lot on CPU design and it shows; ARM's Cortex performance for things like NEON is way, way worse.
From my impressions of seeing how these get implemented, it seems like some hardware features end getting added to the chip by the hardware team and then the software engineers get told that it now exists. So that’s another reason why I doubt that they are “cheating” on benchmarks.
Earlier quoted context omitted.
Implementing the memory ordering in hardware is a huge performance benefit, but they didn’t have to do it with a switch like they have right now. ARMv8.4-RCpc would be enough, and I believe M1 supports these too. (FWIW, Rosetta itself does “cheat”: the translated code and the runtime shares an address space, and memory accesses are not checked, so it’s possible to write an “Intel” binary that is aware of the runtime…
Isn't it a switch because the weak memory model, whilst providing less guarantees is more performant?. So they are trying to have both the x86 mode which isn't as performant, but works a lot faster in hardware than the software implementation and the faster weaker ARM model.
"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.
Refcounting in a single-threaded context is extremely quick and efficient. What's expensive is atomic reference counting, as seen e.g. in C++ shared_ptr and Swift ARC.
Another thing is apparently their branch predictor is specially tuned to work with how Objective-c dispatch works (which iirc Swift inherits in places too, and not just when interfacing with Obj-C APIs)
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.
Some examples
>Decode:
What really defines Apple’s Firestorm CPU core from other designs in the industry is just the sheer width of the microarchitecture. Featuring an 8-wide decode block, Apple’s Firestorm is by far the current widest commercialized design in the industry.
Re-order Buffer:
A +-630 deep ROB is an immensely huge out-of-order window for Apple’s new core, as it vastly outclasses any other design in the industry. Intel’s Sunny Cove and Willow Cove cores are the second-most “deep” OOO designs out there with a 352 ROB structure, while AMD’s newest Zen3 core makes due with 256 entries, and recent Arm designs such as the Cortex-X1 feature a 224 structure.
Execution Units:
On the Integer side, we find at least 7 execution ports for actual arithmetic operations. These include 4 simple ALUs capable of ADD instructions, 2 complex units which feature also MUL (multiply) capabilities, and what appears to be a dedicated integer division unit.
On the floating point and vector execution side of things, the new Firestorm cores are actually more impressive as they a 33% increase in capabilities, enabled by Apple’s addition of a fourth execution pipeline. The FP rename registers here seem to land at 384 entries, which is again comparatively massive. The four 128-bit NEON pipelines thus on paper match the current throughput capabilities of desktop cores from AMD and Intel, albeit with smaller vectors.
Cache:
Apple’s designs are monstrous, and the A14 Firestorm cores continue this trend. Last year we had speculated that the A13 had 128KB L1 Instruction cache, similar to the 128KB L1 Data cache for which we can test for, however following Darwin kernel source dumps Apple has confirmed that it’s actually a massive 192KB instruction cache. That’s absolutely enormous and is 3x larger than the competing Arm designs, and 6x larger than current x86 designs, which yet again might explain why Apple does extremely well in very high instruction pressure workloads, such as the popular JavaScript benchmarks.
The huge caches also appear to be extremely fast – the L1D lands in at a 3-cycle load-use latency. AMD has a 32KB 4-cycle cache, whilst Intel’s latest Sunny Cove saw a regression to 5 cycles when they grew the size to 48KB.
https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de...
There are plenty of other details in the piece, although bear in mind that the M1 is more beefy than the A14 detailed here (more i/o bandwidth, larger system cache, etc.).
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.
The set of x86 instructions people actually use is sufficiently small that the (ignoring the amortized cost of the rest of the ISA - it should be considered, but we can't really know how much space it actually takes up on the die) the two architectures have, to first order at least, converged such that the tricks are now all in the details like memory ordering and scheduling than the actual instructions as per se.
Earlier quoted context omitted.
i believe in this case cheating is being used to mean that they were clever, working around the problem, not doing anything wrong
Yeah. "How do we make the Wii run Game Cube games? We cheat by putting a Game Cube in the Wii!" It's a playful use of the term.
Edit: Lol I know, downvote away, icgaf I haven’t played a game besides minesweeper in months.