81–90 of 196 posts
Earlier quoted context omitted.
I think the M1 macs are the first really significant product that Apple has introduced since Steve Job's death.
Apple Watch put a Unix computer with a 16-hour battery life, an LTE modem & multiple health sensors on my wrist. I’d count that as significant.
Can anyone explain what they did exactly?
Also, what are their JavaScript specific instructions?
> 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).…
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.
2020 is finally the year of RISC on the desktop
Well, maybe... “ On Friday, September 1, 2017, after a round of layoffs that started in Oracle Labs in November 2016, Oracle terminated SPARC design after the completion of the M8. Much of the processor core development group in Austin, Texas, was dismissed, as were the teams in Santa Clara, California, and Burlington, Massachusetts.[4][5] SPARC development continues with Fujitsu returning to the role of leading provider of SPARC servers, with a new CPU due in the 2020 time frame.”
> 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.
The POWER7 through POWER9 processors from IBM implement an equivalent to this called "SAO", or "Strong Access Ordering Mode". To quote an IBM engineer:
> Currently, power has a weaker memory model than x86. Implementing a stronger memory model allows an emulator to more efficiently translate x86 code into power code, resulting in faster code execution.
You'll see just how deep down support for this mode goes. To implement this sort of strong memory ordering requires modifications e.g. SAO mode introduces a new pipeline hazard to the L2 cache and requires deep support in the MMU, including corner cases like the virtual memory for VMs and nested VMs.
It's not a casual addition to the uarch.
EDIT:
It just occurred to me Apple has taken a very different approach to solving this problem.
From what I can tell, TSO on apple's CPUs is just process state implemented in their "high performance" cores that you get from flipping a bit in the MSR register (?).
IBM's version is implemented in the memory system, and is applied to pages of memory (on Linux you call mprotect to mark a page SAO). TSO-semantics are then applied regardless of which core on a potentially multiprocessor, SMP system accesses it.
The Apple implementation seems to be more limited -- but in a totally inconsequential way (can't share data between TSO and non-TSO processes). But it does beg the question, what happens when you have shared memory between a Rosetta 2 process and native ARM code? If the ARM code is running on a core without TSO, what gremlins come out to eat your data?
[0] https://www.setphaserstostun.org/power9/POWER9_um_OpenPOWER_...
> 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'm curious if this means that while any app is running in Rosetta2, does that mean the entire M1 CPU is in "Intel TSO mode", and therefore all processes run slower as a result, or can it do that for just the Rosetta2 Process(es)?
Anandtech has already posted a list of ways that Apple's big ARM core implementation (in the iPhone version of the chip) differs from industry norms, ARM and x86. 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…
You've got to wonder what 3nm will bring, not just for Apple, but for the CPU industry in general.
Comparing the 7nm AMD Zen 3 to the 5nm A14 leads to a simple extrapolation to 3nm: we could see 256KB+ L1 caches, 1K deep ROBs, etc...
Earlier quoted context omitted.
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).…
Reference counting cannot be faster than naive manual memory management because it does the same thing with the additional overhead of reference counting. Even a very simple generational GC beats naive explicit memory management on most nontrivial workloads given enough memory. https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf
>>>We use this framework to compare the time-space performance of a range of garbage collectors to explicit memory management with the Lea memory allocator. Comparing runtime, space consumption, and virtual memory footprints over a range of benchmarks, we show that the runtime performance of the best-performing garbage collector is competitive with explicit memory management when given enough memory. In particular, when garbage collection has five times as much memory as required, its runtime performance matches or slightly exceeds that of explicit memory management. However, garbage collection’s performance degrades substantially when it must use smaller heaps. With three times as much memory, it runs 17% slower on average, and with twice as much memory, it runs 70% slower. Garbage collection also is more susceptible to paging when physical memory is scarce. In such conditions, all of the garbage collectors we examine here suffer order-of-magnitude performance penalties relative to explicit memory management.GC is "competitive" when is has 5x as much memory according to the authors. Well, probably this is because GCs are fast when they have low to no memory pressure. They simply don't need to garbage collect anything. In fact, a non-collecting, non-managed, memory approaches can be faster than any memory management. That is, you have a short lived application that just allocates what it needs, never frees anything, then dies when done. But this is not apples to apples.
The paper also says that with 2x more memory than manual management, GC is 70% slower and under paging scenarios GC can suffer "order-or-magnitude performance penalties relative to explicit memory management."
Except under unusual conditions, there is no case where GC is faster than manual.
> 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.
> When running translated x86 code, they switch the mode of the CPU to conform to Intel's memory ordering. I'm curious if this means that while any app is running in Rosetta2, does that mean the entire M1 CPU is in "Intel TSO mode", and therefore all processes run slower as a result, or can it do that for just the Rosetta2 Process(es)?
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.
As far as I understand, AMD has come out and set it does not make sense for them to make wider than 4 instruction decoders. It seems the CISC architecture creates an upper limit for decoders, as complexity rapidly grows when you have no idea where the next instruction begins in a variable length ISA. So Apple has twice as many decoders, eight, and may actually be able to keep adding to that number while AMD and Intel…
I'm not sure why everyone focuses on the decoders as the primary determinant of width. There are other bottlenecks which may be narrower than the decoders, and the decoders may not even be used when a uop cache or something like a "loop buffer" (LSD on Intel) is present.
So AMD doesn't believe that wider chips aren't useful or that 4 is a limit, because they went to 5-wide in Zen (or 6, depending on how you count it) and I expect them to go wider in the future.
Intel went from 4 wide (narrowest bottleneck) to 5 wide in Ice Lake.
Wider chips are the future, and there is no "hard wall" at 4 for x86, just like any earlier width increase: just constantly diminishing returns.