Apple M2 Die Shot and Architecture Analysis – Big Cost Increase and A15 Based IP • Hacker News Board

Re: Apple M2 Die Shot and Architecture Analysis – Big Cost Increase and A15 Based IP

#71

Post by inkyoto » Sat, Jun 11, 2022, 5:23 AM UTC

modeless wrote: post #67

inkyoto wrote: post #45

Earlier quoted context omitted.

> No, it's because they lost the lead in fabs. AMD passed Intel, was it because of their designs? No, it's because they use TSMC's fabs and TSMC passed Intel. Apple blew everyone away with M1, was it because of their designs? No, it's because they paid TSMC boatloads of money for exclusivity on their latest fabs . The fixation on the fab process is bewildering. Yes, it does help, but it is also an optimisation step t…

Stuff like adding SVE2 can be great for specific applications but it's really marginal when looking at whole system performance. What's not marginal are the improvements in power efficiency and room for more cache that come with new process nodes. These chips are power constrained in almost everything they do, because of heat dissipation or battery life or both. Less power and more cache benefits everything automatic…

> Stuff like SVE2 is really marginal when looking at whole system performance.

It is not. A recent paper (https://arxiv.org/pdf/2205.05982.pdf) from Google engineering has compared performance of a vectorised (SIMD) vs non-vectorised implementation of the quick sort in the Highway library as well as the performance difference of the AVX-512 vs NEON/SVE1 implementations. By switching to the SIMD processing alone, the 9-19x speedup has been reported, depending on the SIMD unit size (32/64/128-bit numbers have been sampled and measured up). Even the smallest of the two, the 9x perfomance gain factor, is far from being marginal.

On the SIMD unit size of things, the performance difference between AVX-512 (the average of 1120 Mb/sec has been measured) and NEON implementation (the 478 Mb/sec throughput on average) is 2.4x smaller for NEON/SVE1 largely due to the smaller width of the units of processing. Again, the 2.4x factor is not in the marginal territory.

> What's not marginal is the improvements in power efficiency that come with new process nodes.

And that is an optimisation step, albeit a very important one. However, it will not make a quick sort implementation run 2.4x faster alone.

Re: Apple M2 Die Shot and Architecture Analysis – Big Cost Increase and A15 Based IP

#72

Post by modeless » Sat, Jun 11, 2022, 5:30 AM UTC

inkyoto wrote: post #71

modeless wrote: post #67

Earlier quoted context omitted.

Stuff like adding SVE2 can be great for specific applications but it's really marginal when looking at whole system performance. What's not marginal are the improvements in power efficiency and room for more cache that come with new process nodes. These chips are power constrained in almost everything they do, because of heat dissipation or battery life or both. Less power and more cache benefits everything automatic…

> Stuff like SVE2 is really marginal when looking at whole system performance. It is not. A recent paper ( https://arxiv.org/pdf/2205.05982.pdf ) from Google engineering has compared performance of a vectorised (SIMD) vs non-vectorised implementation of the quick sort in the Highway library as well as the performance difference of the AVX-512 vs NEON/SVE1 implementations. By switching to the SIMD processing alone, th…

You completely ignored the "whole system performance" part of my statement. What percentage of your CPU time is spent running SIMD-optimized implementations of Quicksort? Now apply Amdahl's law.

Re: Apple M2 Die Shot and Architecture Analysis – Big Cost Increase and A15 Based IP

#73

Post by otikik » Sat, Jun 11, 2022, 5:31 AM UTC

riffraff wrote: post #69

TylerE wrote: post #38

Earlier quoted context omitted.

Things don't become the "est" anything by being wasteful.

My dad used to tell a story when as a kid he worked at a gas station. Guy shows up with a Ferrari, asks for a full tank, pays with a large note and my dad asks him to keep the change. The guy replied - boy, I got a lot of money Really, a lot. You know how I got them? I never gave anything away for free. Hand that change over.

That just illustrates that a lot of rich guys are entitled assholes. The correlation between assholery and driving an expensive car in particular has been studied.

https://youtu.be/1EHhFwGeQLc

Re: Apple M2 Die Shot and Architecture Analysis – Big Cost Increase and A15 Based IP

#74

Post by krasin » Sat, Jun 11, 2022, 5:32 AM UTC

wbl wrote: post #59

krasin wrote: post #48

Earlier quoted context omitted.

I am curious. Would it be possible to provide a more direct reference?

https://en.m.wikipedia.org/wiki/Go_West,_young_man

Thanks! Apparently, I knew the quote, but not the author of it.

Re: Apple M2 Die Shot and Architecture Analysis – Big Cost Increase and A15 Based IP

#75

Post by travisgriggs » Sat, Jun 11, 2022, 5:42 AM UTC

It’s dated, and the subject has shifted to processor design, but

The Apple Product Cycle (https://misterbg.org/AppleProductCycle.html)

still sums it all up pretty well.

Re: Apple M2 Die Shot and Architecture Analysis – Big Cost Increase and A15 Based IP

#76

Post by brigade » Sat, Jun 11, 2022, 5:51 AM UTC

inkyoto wrote: post #71

modeless wrote: post #67

Earlier quoted context omitted.

Stuff like adding SVE2 can be great for specific applications but it's really marginal when looking at whole system performance. What's not marginal are the improvements in power efficiency and room for more cache that come with new process nodes. These chips are power constrained in almost everything they do, because of heat dissipation or battery life or both. Less power and more cache benefits everything automatic…

> Stuff like SVE2 is really marginal when looking at whole system performance. It is not. A recent paper ( https://arxiv.org/pdf/2205.05982.pdf ) from Google engineering has compared performance of a vectorised (SIMD) vs non-vectorised implementation of the quick sort in the Highway library as well as the performance difference of the AVX-512 vs NEON/SVE1 implementations. By switching to the SIMD processing alone, th…

Soo... basically a 2x speedup in going from 4x128b to 2x512b ALUs, after discounting the frequency difference. But realistically, Intel's client configurations are 3x256b, which is only 25-40% faster in that paper.

(I suspect any application doing enough quicksort that the 2x speedup is significant, would be even happier going slightly off-core to a coprocessor more specialized in vector processing, like Hwacha. There's plenty of space between "tightly-coupled CPU SIMD" and "GPU" that I think makes more sense than needing to implement 512-bit registers in little cores.)

Re: Apple M2 Die Shot and Architecture Analysis – Big Cost Increase and A15 Based IP

#77

Post by inkyoto » Sat, Jun 11, 2022, 5:53 AM UTC

brigade wrote: post #60

inkyoto wrote: post #45

Earlier quoted context omitted.

> No, it's because they lost the lead in fabs. AMD passed Intel, was it because of their designs? No, it's because they use TSMC's fabs and TSMC passed Intel. Apple blew everyone away with M1, was it because of their designs? No, it's because they paid TSMC boatloads of money for exclusivity on their latest fabs . The fixation on the fab process is bewildering. Yes, it does help, but it is also an optimisation step t…

Android flagships are shipping with SVE2 as of this year, which I actually didn't realize until like two weeks ago because there's been nearly zero buzz about it. What's SVE2 being used for over NEON as of now?

Low level runtime optimisation that yields substantial performance gains in the user facing or system level software, ranging from cryptography through to data processing algorithms and very high throughput JSON parsing.

Take OpenSSL as an isolated example. By simply fiddling with the C compiler flags to allow it to use NEON on M1, the sha256 calculation speed-up is 4x for 128 and 256 block sizes, with performance gains quickly tapering off for larger block sizes and resutling in a modest 10% increase only. And that performance increase happens without the involvement of hash functions having been manually optimised for NEON/SVE1.

SVE2 with its variable vector size support could improve performance for larger unit sizes. Perhaps it is the time to spin up a Graviton3 instance and poke around with clang/gcc to see how actually good or faster the SVE2 is.

Re: Apple M2 Die Shot and Architecture Analysis – Big Cost Increase and A15 Based IP

#78

Post by dylan522p » Sat, Jun 11, 2022, 6:00 AM UTC

wmf wrote: post #25

dagmx wrote: post #19

Earlier quoted context omitted.

The author has been pushing this conjecture for a year over the past year or so, and has been repeatedly called out on the Hardware reddit. I would recommend not taking their business conjecture without a giant pinch of salt. Just today they were claiming Apple has lost hundreds of engineers in the chip division. The idea that a single division somehow lost hundreds without the industry noticing is ridiculous.

Why do you think the industry hasn't noticed? If it's not hundreds, how many Apple employees have moved to Nuvia and Rivos?

It has noticed. Look at Apple architects, validation, layout, etc engineers moving to Nuvia + Rivos + Google + Amazon + Microsoft + Meta + Intel + Nvidia + AMD + Apple + Qualcomm.

It's there.

Re: Apple M2 Die Shot and Architecture Analysis – Big Cost Increase and A15 Based IP

#79

Post by inkyoto » Sat, Jun 11, 2022, 6:01 AM UTC

modeless wrote: post #72

inkyoto wrote: post #71

Earlier quoted context omitted.

> Stuff like SVE2 is really marginal when looking at whole system performance. It is not. A recent paper ( https://arxiv.org/pdf/2205.05982.pdf ) from Google engineering has compared performance of a vectorised (SIMD) vs non-vectorised implementation of the quick sort in the Highway library as well as the performance difference of the AVX-512 vs NEON/SVE1 implementations. By switching to the SIMD processing alone, th…

You completely ignored the "whole system performance" part of my statement. What percentage of your CPU time is spent running SIMD-optimized implementations of Quicksort? Now apply Amdahl's law.

«Whole system performance» is a meaningless term as it is a function of many, usually poorly controlled, input variables, and your whole system is different from my whole system. If my VPN tunnel allows me to have faster transfer speeds simply by virtue of having ISA assisted optimisations in the cryptographic library it uses, the net result will be very noticeable to me but perhaps not for you unless you also have to use the same VPN client.

Even the web browser you are using right now to comment on HN likely makes use of the very same Highway library (Chrome and Firefox certainly do, unsure about Safari) the speedup gains have been reported for. The «overall» browser performance will also improve as the result due to it receiving gains transparently, by simply dropping an optimised implementation into the browser build.

Re: Apple M2 Die Shot and Architecture Analysis – Big Cost Increase and A15 Based IP

#80

Post by Jyaif » Sat, Jun 11, 2022, 6:02 AM UTC

brokencode wrote: post #24

Why does the biggest and richest company in the world ever have to suffer from talent leaving because they don’t get paid enough? It just doesn’t make any sense.

There are a downsides to paying a lot:

* you attract/retain more people that are interested in money/status.

* the employees become entitled.

Also, just like Apple's customers are OK with paying a premium price because it's Apple, employees are OK with paying a premium price to be an employee of Apple (by accepting lower salaries).