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

121–130 of 196 posts

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

#121

Post by simonh »

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.

I suppose so, but who was saying this in 2014 and 2015 when the other smart watches were out and Apple's offering was only a rumour? Back then the consensus was the watch would be a watershed test of whether the team at Apple had it in them. Now that they've conclusively nailed it, we discover it didn't count after all.

Of course the expectation was that the Apple Watch should be just as popular as the iPhone and transcend the watch industry completely. Wearables would be the next utterly indispensable technology, maybe even threatening the phone itself. In comparison, 'merely' dominating the existing watch industry and gobbling large chunks of the fitness tracker market seems underwhelming.

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

#122

Post by rini17 »

phs318u wrote: post #32
dmart wrote: post #5

Earlier quoted context omitted.

This was a legitimate criticism back when there was no way to thread tweets and you had to read them in reverse. Now that you just scroll down like any other website, it just sounds like tired complaining.

This complaint is about more than mere website formatting (per HN guidelines). There's now 11 distinct reply threads of fragmented discussion to dig into, for anyone that might be interested. Hokusai is right to complain about this. And people savvy enough to write the article should know better. Post it on a blog and tweet the link. How hard is that?

It is hard, some people are plainly incapable of expressing themselves in article form. Or refuse to. There was plenty of shaming already and it did not help.

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

#123

Post by vaxman »

vaxman wrote: post #84
pram wrote: post #59

Earlier quoted context omitted.

2020 is finally the year of RISC on the desktop

uh, no. 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 lead…

How long before 2020 Fujitsu rebinned SPARC chips are sold to OEMs for SPARCstations runnin’ popOS?

It’s not like System76 is going to be able to buy M1s (dang sounds like a weapon when you put it that way ) and Ryzen might not compete with near term successors to M1.

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

#124

Post by gpderetta »

spijdar wrote: post #85
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.

To add to this: 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. What's interesting is IBM publishes pretty detail…

I don't think sharing is a big issue: TSO has some implicit acquire and releas barriers on read and writes, so the weaker side just needs to issue the relevant barriers explicitly.

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

#125

Post by pjmlp »

pram wrote: post #59
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.

2020 is finally the year of RISC on the desktop

I thought it was during the 80's and early 90's.

https://en.wikipedia.org/wiki/Acorn_Archimedes

https://en.wikipedia.org/wiki/Silicon_Graphics#RISC_era

https://en.wikipedia.org/wiki/HP-UX#BL_series

https://en.wikipedia.org/wiki/SPARCstation

https://en.wikipedia.org/wiki/NeXT#1987%E2%80%9393:_NeXT_Com...

https://en.wikipedia.org/wiki/BeBox

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

#126

Post by crubier »

bredren wrote: post #94
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.

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 evolu…

> “But the true product of Apple has been focused iterative delivery.”

... Excepted that this is not a product, be any definition ever.

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

#127

Post by sirn »

BeeOnRope wrote: post #90
socialdemocrat wrote: post #76

Earlier quoted context omitted.

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…

Intel has been at 5 decoders since Skylake (~2015). 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…

Isn't the extra 2 on Zen not a decoder unit, but rather a 6-way dispatch[1] with op-cache being used to kept the execution unit busy? Or was that the reason behind calling it a 5 or 6-wide depending on how one's may count it considering cache miss and all?

[1]: https://images.anandtech.com/doci/16214/Zen3_arch_5.jpg

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

#128

Post by pram »

pjmlp wrote: post #125
pram wrote: post #59

Earlier quoted context omitted.

2020 is finally the year of RISC on the desktop

I thought it was during the 80's and early 90's. https://en.wikipedia.org/wiki/Acorn_Archimedes https://en.wikipedia.org/wiki/Silicon_Graphics#RISC_era https://en.wikipedia.org/wiki/HP-UX#BL_series https://en.wikipedia.org/wiki/SPARCstation https://en.wikipedia.org/wiki/NeXT#1987%E2%80%9393:_NeXT_Com... https://en.wikipedia.org/wiki/BeBox

it was a joke. apple has literally made RISC desktops before (which you failed to link)

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

#129

Post by gpderetta »

annilt wrote: post #30
muststopmyths wrote: post #13

>8/ Another "magic" trick is how their "Swift" programming language uses "reference counting" instead of the "garbage collection" in Android. They did something in their CPU to double the speed of reference counting. What the hell does that even mean ? Disregarding the nonsensical attribution of magic to Swift vs Java, if "reference counting" on translated x86 code is faster, then I suppose M1 does "lock add / cmpxch…

I think it says refcounting twice faster for swift on M1 compared to swift on x86. It is possible because if you don’t have TSO(total store order), you can employ atomic operations without waiting/flushing previous items in the CPU’s store buffer

But apparently they are faster even in TSO mode.

Maybe they aggressively speculate around them.

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

#130

Post by pjmlp »

pram wrote: post #128
pjmlp wrote: post #125

Earlier quoted context omitted.

I thought it was during the 80's and early 90's. https://en.wikipedia.org/wiki/Acorn_Archimedes https://en.wikipedia.org/wiki/Silicon_Graphics#RISC_era https://en.wikipedia.org/wiki/HP-UX#BL_series https://en.wikipedia.org/wiki/SPARCstation https://en.wikipedia.org/wiki/NeXT#1987%E2%80%9393:_NeXT_Com... https://en.wikipedia.org/wiki/BeBox

it was a joke. apple has literally made RISC desktops before (which you failed to link)

Indeed, but my list wasn't going to be exhaustive anyway.
Post reply on HN