Live data from Hacker News

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

twitter.com

191–196 of 196 posts

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

#191

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…

This is the kind of thing I expected to see Apple throw at the CPU design, given the availability of high transistor density of the 5nm TSMC process. 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...

What kind of limits do Apple face in adding more cores. I don't have a good sense of how big these Firestorm cores are compared to say Zen3. Or how big the overall chip is and what the size limitations are.

Like say you have the Ampere Altra Max with 128 cores ARM processor. Can Apple do that theoretically or is Ampere only able to do that because they make significantly smaller cores, or is it perhaps because they don't have an SoC.

I am just trying to understand better the tradeoffs between smaller weaker cores vs lager but fewer cores. Like if Apple wants to compete in the top end where e.g. AMD has 64 cores. Will that even be possible for Apple?

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

#192

Earlier quoted context omitted.

Adapting to advancing hardware isn't impossible. It's been awhile since I've looked so details are a little hazy, but I know the Mill architecture had an answer to this. I believe they were using effectively two-pass compilation. The first compiled against an abstract version of the architecture, and this is what was distributed. Then this could be further specialized on the user's machine as at that point the limits…

You are correct that with a lot of effort you can get a compiler to emit VLIW instructions that can claw back some of these problems and have some, but not all, of the information you have available to the processor core at runtime which can make things slightly smarter. And with all of that effort which involves changing software distribution models, jettisoning energy efficient flexible heterogenous architectures,…

> Not sure why anyone thinks that’s an argument for doing it.

Because it didn't take very much effort and it doesn't require changing distribution models or abandoning those things.

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

#193
post #145

Earlier quoted context omitted.

You (and apparently most of HN) is misunderstanding me: I’m not saying Apple isn’t doing great stuff or that they’re just coasting on ARMs tech, but it is the ARM ISA that enables them to make the M1 so ridiculously good. But people won’t believe that and will attribute it to Apple’s vertical integration until they are holding a Windows laptop with an ARM CPU and crazy battery life, thermals etc. And again: ARM alrea…

No, we understand fine; we disagree with the claim that M1 is good because of the ARM ISA. Had Apple picked something else a decade ago we’d probably see them pulling ahead with that, too.

Then you don’t really understand, because Apple couldn’t have pushed x86 this far, even if they had gotten a license.

Also go pick a bone somewhere else man, how sad do you have to be to multi-downvote on HN? This isn’t Reddit.

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

#194
post #193

Earlier quoted context omitted.

No, we understand fine; we disagree with the claim that M1 is good because of the ARM ISA. Had Apple picked something else a decade ago we’d probably see them pulling ahead with that, too.

Then you don’t really understand, because Apple couldn’t have pushed x86 this far, even if they had gotten a license. Also go pick a bone somewhere else man, how sad do you have to be to multi-downvote on HN? This isn’t Reddit.

I fail to see why Apple could not have pushed x86 "this far". I'd be happy to hear why you think so, though. I don't really understand the second part of your comment, however: I have no bone to pick with you, nor do I regularly downvote people. Least of all you, since the only interaction I recall having with you is your replies to my comments, which automatically disables downvoting.

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

#195

Earlier quoted context omitted.

You are misunderstanding this paper deeply. Quoted summary from the paper itself: >>>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 comp…

I understood that part completely. You misunderstood my point, which is that with enough memory, generational GC outperforms naive explicit memory management, which is impossible with reference counting. > Except under unusual conditions, there is no case where GC is faster than manual. Their simple generational GC outperforms manual memory management in every single workload in that paper given enough memory, so tha…

Isn't it amazing how your well-informed comments get downvoted?

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

#196
post #102

Earlier quoted context omitted.

That's because apple bought the entire 5nm production capacity/runs for basically for the entire last quarter of 2020. I can tell you some companies were not too pleased about that.

Which companies?

AMD.
Post reply on HN