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

71–80 of 196 posts

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

#71

Post by neerajsi »

saagarjha wrote: post #65
_kbh_ wrote: post #62

Earlier quoted context omitted.

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.

The thing I mentioned should be better in that case since it’d enforce the right memory ordering on a per-instruction basis.

The ls/st instructions take a large amount of encoding space for all the addrmodes. I don't think the rcpc instructions and other acq/rel instructions were given the same encoding space.

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

#72

Post by twoodfin »

PopePompus wrote: post #67
coliveira wrote: post #41

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.

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.

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

#73

Post by dylz »

devin wrote: post #61
loeg wrote: post #50

Earlier quoted context omitted.

FWIW, the name is HEVC or H.265. AVC is H.264.

This yes, but it still gave me a chuckle to read HVAC, because I often see HEVC and think HVAC.

I do need a significant amount of cooling when doing GPU-heavy things.

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

#74

Post by PopePompus »

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.

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.

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

#75

Post by GeekyBear »

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.

> The Apple Watch is a successful product, but it really didn't completely disrupt a large existing industry

For some values of large?

>Apple now sells more watches than the entire Swiss watch industry

https://www.theverge.com/2020/2/5/21125565/apple-watch-sales...

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

#76

Post by socialdemocrat »

pythonvisa wrote: post #12

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 may get stuck on 4, thanks to the x86 CISC legacy.

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

#77

Post by nickysielicki »

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 some time, but people (AMD/Intel) were not brave enough to fix them because they didn't have adequate control of their software ecosystem to say, "Your software from your old computer will not run/will not run as well on your new computer." (For emphasis, let me just put it clearly what I'm claiming: x86 was designed in the 1970s. This is what happens when you use an ISA that was not designed in the 1970s.)

Apple, however, does have control of their ecosystem, and they're allowed to be brave, provided they can support their ecosystem.

Here's my hot take: Intel tried to be brave with Itanium, but failed because compilers weren't up to the job at the time. That's changed. First things first, we're going to see mainstream desktop-class/laptop-class ARM being extended to linux and Windows. But I also believe that sometime in the next ten years, after all this newfangled high-performance ARM stuff is sorted out, we're also going to see someone give VLIW another shot, and they're going to succeed this time.

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

#78

Post by lern_too_spel »

GeekyBear wrote: post #75
PopePompus wrote: post #74

Earlier quoted context omitted.

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.

> The Apple Watch is a successful product, but it really didn't completely disrupt a large existing industry For some values of large? >Apple now sells more watches than the entire Swiss watch industry https://www.theverge.com/2020/2/5/21125565/apple-watch-sales...

The Swiss watch industry isn't what it was. Most people I know don't wear a watch.

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

#79

Post by rayiner »

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…

Thanks. These articles focusing on stuff like JavaScript instructions as being the reason the M1 is so fast are off the mark. Apple implemented an 8-wide out of order core. That’s not only a huge accomplishment. But it defies what was until recently conventional wisdom: that going much beyond a 4-wide core would be well past the point of diminishing returns in an OOO core.

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

#80

Post by vlovich123 »

gameswithgo wrote: post #63
barnaclejive wrote: post #37

Earlier quoted context omitted.

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.

may also apply to Rust where we often make use of reference counting when the borrow checker isn’t enough

ARC probably yes (assuming the standard library annotates the atomic operations properly). RC no. That being said, it sounds like in general uncontended atomic operations are faster so this might benefit a lot of atomic code in any language.
Post reply on HN