Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

twitter.com

Post reply on HN
Print view View original

91–100 of 196 posts

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

#91

Post by atq2119 »

nickysielicki wrote: post #77
saagarjha wrote: post #51

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 reality is that the reasons these chips are fast are either unknown or boring. I suspect that these will one out as we play around with them more, but we don’t have the details right now. I disagree, I think we have plenty of information. This is what happens when a huge proportion of your die isn't doing instruction decoding. x86/amd64 are old and crufty. Lessons have been learned, and had been learned for som…

This is what happens when a huge proportion of your die isn't doing instruction decoding.

That's a misconception. Yes, decoding x86 is somewhat more complicated, as far as I'm aware that's mostly because instruction length differs at a byte granularity. Still, the area dedicated to it simply isn't that large on those huge out of order designs.

I'm sure the instruction encoding plays some role, but I suspect what we're seeing is rather down to consistently good micro-architecture execution over the years and Apple being ahead of everybody else on manufacturing process.

Compared to the x86 processors that exist today, M1 also benefits from having the memory in-package.

Intel tried to be brave with Itanium, but failed because compilers weren't up to the job at the time.

Compilers "failed" because VLIW is fundamentally not a particularly useful idea. The main problem for general purpose single-thread performance is memory latency, and VLIW just doesn't help there.

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

#92

Post by ksec »

GeekyBear wrote: post #68

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…

I wish more people just read Anandtech ( which is a well established Site, no idea why many are not reading it ) but decide to make crap up like this twitter thread.

Javascript instruction has nothing to do with it and even JSC guy from Apple confirms it. ( The instruction wasn't even used at the time the comparison was written )

And the memory model isn't even cheating or specific to Intel x86.

And the worst of all it is getting freaking hyped up all over the place even on HN. It is like watching misinformation spreading like wild fire in real time.

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

#93

Post by saagarjha »

BeeOnRope wrote: post #89
grecy wrote: post #86

Earlier quoted context omitted.

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

I don't have any specific info, but I would be very surprised if this MSR setting wasn't on a per-core basis. So only cores that are currently running code that requires x86-TSO would be running in that mode.

Per core, yes. It gets set on entry and exit from the kernel for threads that have been marked as needing it.

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

#94

Post by bredren »

twoodfin wrote: post #72
PopePompus wrote: post #67

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.

Both of these comments miss the point.

The most significant product produced since Jobs passing is the continuous focus on developing technology in the open that can ultimately be applied to groundbreaking products.

The M1 is the natural evolution of the A series processors and the software development tools Apple has been working on in the open for years.

The next major mobile product from Apple is the natural evolution of the micronization of hardware systems seen on the Apple Watch, tied together with secure and private storage of personal data.

Like iPhone and iPad, Apple Watch is a great product in of itself. But the true product of Apple has been focused iterative delivery.

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

#95

Post by spijdar »

brigade wrote: post #25
zozbot234 wrote: post #7

Earlier 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

Still implemented up to POWER9 as well, due to problem-state backwards compatibility by two generations I presume.

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

#96

Post by iamAtom »

PopePompus wrote: post #74
twoodfin wrote: post #72

Earlier quoted context omitted.

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.

Well, I respectfully disagree. The Apple Watch is a successful product, but it really didn't completely disrupt a large existing industry like the iPhone did. I think it's possible that the M1 will trigger the death of x86 personal computers. If that happens, it won't have been an iPhone-level disruption, but it will be a lot more significant than the watch.

"it really didn't completely disrupt a large existing industry" - Have you checked market share of Apple Watch ?

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

#97

Post by simonh »

jorvi wrote: post #56
saagarjha wrote: post #51

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…

People won’t believe it’s not Apple its magic sauce and ARM is really just that good until ARM processors start being a mainstream thing in Windows laptops. ARM its ARM-X already looks pretty juicy and the follow-ups are sure to get better and better.

If Apple is free riding on how great ARM is, how come everybody else’s mobile ARM chips are such pants in comparison?

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

#98

Post by danmaz74 »

atq2119 wrote: post #91
nickysielicki wrote: post #77

Earlier quoted context omitted.

> The reality is that the reasons these chips are fast are either unknown or boring. I suspect that these will one out as we play around with them more, but we don’t have the details right now. I disagree, I think we have plenty of information. This is what happens when a huge proportion of your die isn't doing instruction decoding. x86/amd64 are old and crufty. Lessons have been learned, and had been learned for som…

This is what happens when a huge proportion of your die isn't doing instruction decoding. That's a misconception. Yes, decoding x86 is somewhat more complicated, as far as I'm aware that's mostly because instruction length differs at a byte granularity. Still, the area dedicated to it simply isn't that large on those huge out of order designs. I'm sure the instruction encoding plays some role, but I suspect what we'r…

Doesn't Apple use TSMC manufacturing?

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

#99

Post by ithkuil »

grecy wrote: post #86
titzer wrote: post #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.

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

A cpu (core) executes one process at a time. There is a lot of cpu (core) global state that gets saved / restored upon context switch (either between processes or just between user mode and kernel mode).

As a side note, there is a often a bit of terminology confusion on whether a cpu is the "die" or the "core". When discussing microarchitecture core == cpu in most cases

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

#100

Post by ylyn »

danmaz74 wrote: post #98
atq2119 wrote: post #91

Earlier quoted context omitted.

This is what happens when a huge proportion of your die isn't doing instruction decoding. That's a misconception. Yes, decoding x86 is somewhat more complicated, as far as I'm aware that's mostly because instruction length differs at a byte granularity. Still, the area dedicated to it simply isn't that large on those huge out of order designs. I'm sure the instruction encoding plays some role, but I suspect what we'r…

Doesn't Apple use TSMC manufacturing?

Yes, and they are the only ones on TSMC 5nm currently.
Post reply on HN