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

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

semianalysis.substack.com

Post reply on HN
Print view View original

181–190 of 206 posts

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

#181

Post by kristianp »

sushicat wrote: post #58
GeekyBear wrote: post #55

From Anandtech's deep dive into the performance and efficiency cores in the A15, which are reused here in the M2. Performance Cores: >Apple A15 performance cores are extremely impressive here – usually increases in performance always come with some sort of deficit in efficiency, or at least flat efficiency. Apple here instead has managed to reduce power whilst increasing performance, meaning energy efficiency is impr…

This is a really great article from Anandtech with benchmarks and analysis, it explained a lot of things. > The overall performance gains are quite disappointing when you factor in the raw cost increase that comes with this new M2 and the fact that it has been nearly 2 years since the M1’s introduction. Also the logic of article in the title is little weird to me. M1 was introduced in the same year as A14, they use t…

Given that M2 is available in a week or two, and the A16 isn't, I would say it's a scheduling thing. In order to have the M1 to M2 cadence not blow out, they have to make decisions about what can go into the product.

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

#182

Post by jti107 »

MBCook wrote: post #44

Thanks to being based on their phone chips Apple came out of the gate with the M1 and cleaned everyone’s clock on performance-per-watt while putting in good to great numbers in general (as a CPU). But their rate of improvement on the A series has been slowing on general tasks. They’re on the same process node, and only increased frequency a bit. Is it really that surprising that performance didn’t take a massive jump…

ya but you have to look at it in terms of the consumer. not everyone is buying a new iphone every year. most wait two years and two years of 18%+ improvements leads to a phone that feels like a substantial upgrade especially for mobile games, 4k video and computational photography

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

#183

Post by dymk »

GoOnThenDoTell wrote: post #10
dymk wrote: post #6

Earlier quoted context omitted.

Seems like quibbling over words that everybody understands the meaning and intention of

Words matter. Apple failed to retain these employees with cash, its not some hunting game where you catch some unsuspecting engineer

Yeah, they matter, and everybody* understands what "poaching" means when used this way

* - including you

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

#184

Post by cyberpunk »

sangnoir wrote: post #177
cyberpunk wrote: post #120

Earlier quoted context omitted.

If someone asked to keep my change I would say no too. Why the fsck? Is it normal to beg during work where you’re from?

> Is it normal to beg during work where you’re from? Yes - but they call it tipping 'round these parts. They even have prominently displayed tip jars and everything.

Oh I tip plenty; but I’ve never been asked for a tip…

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

#185

Post by janwas »

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…

> 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

Depends on the applications, I suppose. But did you know that (at least on OoO x86), the energy cost of scheduling an instruction dwarfs that of the actual computation? That is why SIMD, including SVE2, can be so important - it amortizes that cost over several elements. Let's spend (more of) our energy budget on actual work.

Is it really just "very few things that actually start using new SIMD"? I'm not a huge fan of autovectorization, but even that is able to vectorize some fraction of STL algorithms. And there are several widely used libraries, including image/video codecs and encryption, that use SIMD and wouldn't be feasible otherwise.

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

#186

Post by janwas »

modeless wrote: post #160
inkyoto wrote: post #96

Earlier quoted context omitted.

It is certainly not laughable to me. You have singled out Quicksort as the sole example of performance gains whereas I have used it as a single isolated example of very large performance gains that can be had. SIMD instructions have seen a lot of other mainstream use cases recently which also includes the memory copying or memcpy(3) optimisations amongst others. Your browser has a Javascript engine, and since it a Ja…

Forget Quicksort. What percentage of your CPU time is spent running SIMD-optimized implementations of anything ? And what percent of those are upgraded to new SIMD instructions each year? And what real world percentage gains are they getting considering other constraints like memory bandwidth, power, etc? The answers to these questions, multiplied together, put a very small upper bound on the overall benefit of new i…

If you're watching videos, quite a lot. Also, of the five image codecs mentioned here to succeed PNG/JPG, all have SIMD-enabled implementations: https://cloudinary.com/blog/time_for_next_gen_codecs_to_deth...

I share your concern about new SIMD instructions not being used. It seems to me we're at an inflection point, though. ISAs such as RISC-V and SVE will enable (properly written) software to benefit from future wider vectors without even recompiling. github.com/google/highway (disclosure: I am the main author) lets you write your code only once, and target newer instructions whenever they are available, with transparent fallback to other codepaths for CPUs.

Given the various physical realities including power efficiency, I believe there will be considerably more SIMD usage within the next few years.

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

#187

Post by janwas »

brigade wrote: post #76
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…

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. Ther…

This is an interesting question. Has there been much uptake of such accelerators/coprocessors? One concern is that by the time the HW is ready, SW wants to do something different, perhaps fusing some other step with the sort. Another is deployability: everyone has SIMD/vectors on board, but even GPUs aren't quite everywhere nor so easy to scale out.

Also, there are now several RISC-V CPUs with 512-bit vectors, and it seems fair to call them little cores especially compared to x86 and M1/M2. Perhaps 512-bit is more feasible (and sensible) than is widely believed?

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

#188

Post by janwas »

inkyoto wrote: post #86
brigade wrote: post #76

Earlier quoted context omitted.

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. Ther…

> 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. 2.4x difference was, in fact, reported, however I still find it somewhat difficult to interpret the reported results. The processing unit size difference alone and the number of LU's can't account for su…

I am that engineer; happy to clarify/go into more detail. First, just to ensure we're on the same page: the speeds we quote are sort goodput, i.e. amount of sorted data produced per time. Memory bus is only incidental to keeping the vector units fed.

The key bottleneck is partitioning. AVX-512 does really well there because it has dedicated compressstore instructions, and it's actually even faster to partition a vector via vperm* (because we only need to do that once, whereas two compressstore are required to partition). So AVX-512 reaches >25 GB/s partition throughput per core; it's instead limited by the memory bandwidth each core can access (around 11 GB/s if a single core is active, less when all are competing for the total "128 GB/s").

By contrast, NEON for example in the M1 has 128-bit vectors. Its "4 vector units" (even if they can actually execute all instructions concurrently, which is not clear to me and unlikely - Intel can also only execute some instructions on certain ports) are definitely not as good as actual 512 bit vectors, because partitioning only has a left and right side, and we don't have enough ILP for each of those to keep 2 vector units busy. Hence NEON reaches 11 GB/s partition throughput. It would seem like this matches Skylake, but no: once a subarray fits into cache, Skylake is freed from the memory bottleneck and is at least twice as fast there (which is a sizable fraction of the total sort time).

Does this help explain the results?

> The test set they used could also fully fit into the L2 cache.

This seems unlikely because we're sorting 8 MB and my understanding is that cores (unless L2==LLC) generally have private, partitioned L2 caches, so 3 MB in the case of M1. Is that incorrect?

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

#189

Post by KptMarchewa »

BackBlast wrote: post #64
sushicat wrote: post #58

Earlier quoted context omitted.

This is a really great article from Anandtech with benchmarks and analysis, it explained a lot of things. > The overall performance gains are quite disappointing when you factor in the raw cost increase that comes with this new M2 and the fact that it has been nearly 2 years since the M1’s introduction. Also the logic of article in the title is little weird to me. M1 was introduced in the same year as A14, they use t…

Phones are the flagship product. They will always get the latest and greatest first, including cores, die shrinks, etc etc.

Power efficiency is more important in phones.

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

#190

Post by antifa »

yieldcrv wrote: post #175
epolanski wrote: post #124

Earlier quoted context omitted.

> I can't really generalize it for rich or poor, I did not see that simple pattern. My SO works as a consultant in a bank here in Rome, Italy. She moved from a bank in the periphery to a very central one in the Parioli neighborhood. There was a night and day difference between her old and new clients in wealth (with the Parioli ones being largely millionaires). Old clients would treat her with the utmost respect and…

some banks waive fees for non profits your bank did not one of my biggest pet peeves is how low-level employees cant tell that their organization isn’t doing the normal thing

Wouldn't surprise if the lady did not have a tax id associated with a non profit.
Post reply on HN