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

131–140 of 196 posts

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

#131

Post by gpderetta »

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 believe power also has an 8-wide decoder.

The interesting thing is the very deep ROB. Conventional wisdom is that because of the cumulative branch misprediction probability, ROBs hit diminishing returns relatively quickly. Apple apparently has a best in class preductor, but still that ROB is huge.

Maybe they do tricks like automatically converting some branches to predication.

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

#132

Post by klelatti »

runeks wrote: post #115
klelatti wrote: post #103

Earlier quoted context omitted.

Not disputing what you're saying on instruction decoding but there is a lot of other stuff on an x86 processor that Apple hasn't needed or chosen to implement: 32bit, AVX, legacy SIMD, legacy modes, Intel Management Engine plus probably a more complex instruction set. Individually these may not make a difference but add them all up ....

> Individually these may not make a difference but add them all up .... ... and it still may not make a difference.

I have AVX512 on my laptop. Is it used by any software I use? No. Does it take up a lot of die area? Definitely.

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

#133

Post by acqq »

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 most informative post at the moment for me, with more detailed technical information for those who are interested in what's actually making Apple's M1 CPU fast, based on the article by Anandtech, is much lower on this page, by GeekyBear:

https://news.ycombinator.com/item?id=25235214

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

#134

Post by Closi »

apendleton wrote: post #104
simonh wrote: post #101

Earlier quoted context omitted.

Wait, where did the goal posts go. Has anyone seen them? I swear they were here a minute ago.

To be fair to the person you're responding to, the goalposts look to have been "disrupt a large existing industry." "Large" is obviously subjective, but if the example of the disrupted industry is the watch industry, "the watch industry isn't large so it doesn't count" is a reasonable response within the constraints of the original goalposts.

But it clearly isn’t a small industry, and wearables are now responsible for c$40bn annual revenue at Apple (includes AirPods now though, also invented after jobs), so dismissing it does seem to be changing the goalposts.

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

#135

Post by gpderetta »

pjmlp wrote: post #120
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…

Intel failed because AMD exists and has a cross license agreement that allowed them to be clever. Without AMD in the picture, Itanium issues would have eventually been sorted out.

Well, yes, if Intel had no competition at all they might have been able to force whatever garbage on the market.

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

#136

Post by pjmlp »

gpderetta wrote: post #135
pjmlp wrote: post #120

Earlier quoted context omitted.

Intel failed because AMD exists and has a cross license agreement that allowed them to be clever. Without AMD in the picture, Itanium issues would have eventually been sorted out.

Well, yes, if Intel had no competition at all they might have been able to force whatever garbage on the market.

I actually liked Itanium and don't see it as garbage, and see as an unfortunate turn of events that I am not running one on this laptop.

Also don't get the point of the cheering for AMD, because apparently many don't get that without Intel licenses, which depend on Intel existence, AMD won't have much to play with anyway.

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

#137

Post by pritovido »

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…

"Tricks" makes great difference in life. I can jump over a meter high with my bicycle because someone who knew did teach me the "bunnyhop trick". That and other "tricks" give you the ability to do things save on a bicycle that most people consider impossible or too risky.

Knowing the tricks of a trade, like software development, means the difference between starving or success.

In the same way there are "tricks" that you know about relationships and money and work that can change your life radically.

Trick in English have different meanings. It can be something intended for deception or illusion, but it could also be a habit or mannerism.

In Apple case, those tricks are not really tricks, but strategic informed decisions.

Apple has lots of knowledge about what the market needs and is willing to pay for, they have access to the purchase data of tens of millions of people.

If you have no access to real information, some decisions of the companies that do will look comical or nonsensical.

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

#138

Post by joachimma »

anfilt wrote: post #102
ylyn wrote: post #100

Earlier quoted context omitted.

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

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.

Is there anything preventing those companies from "ganging" up on Apple and buying capacity jointly? Are they too many and too small? Is it possible to share wafer-space with other companies or does having multiple designs add too much complexity/cost?

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

#139

Post by foerbert »

djcapelis wrote: post #112
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…

> Compilers "failed" because VLIW is fundamentally not a particularly useful idea. I think the problem isn’t just that it’s not particularly useful, but that it’s an actively bad idea. It statically encodes ILP that we get dynamically in chip designs today, which means that ILP can no longer react to changing conditions, like literally any core architecture changes as the underlying hardware evolves (or even on the s…

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 of the hardware would be known.

I don't recall if they had an idea for SMT as well or not. It's possible they wrote it off entirely, particularly after Spectre and all that.

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

#140

Post by beagle3 »

pjmlp wrote: post #136
gpderetta wrote: post #135

Earlier quoted context omitted.

Well, yes, if Intel had no competition at all they might have been able to force whatever garbage on the market.

I actually liked Itanium and don't see it as garbage, and see as an unfortunate turn of events that I am not running one on this laptop. Also don't get the point of the cheering for AMD, because apparently many don't get that without Intel licenses, which depend on Intel existence, AMD won't have much to play with anyway.

20 or so years later, it is my impression that there are no compilers that can do enough ILP (on software not specifically written for the Itanium) to justify the Itanium’s VLIW.

Intel licensed some stuff to Cyrix, VIA, AMD, Harris and possibly others at the time. But if AMD didn’t license AMD64 back (by way of cross licensing) things might have been grim for Intel back in 2003-2008 when AMD was killing it previously.

Intel did nothing out of the goodness of their heart, and neither did AMD - so I’m not sure why it is bothering you that people are cheering for AMD for providing (at this point) a technically and economically better product, and hating on Intel for being a fat cat. The pendulum may swing back sooner or later, both technically/economically and public opinion wise.

Post reply on HN