reroute22

The answer to these sort of questions (OP) is always the same: it was done because it made all the sense in the world to do.

Most likely, 150 GB/s -> 200 GB/s results in a fairly small improvement (when paired with a processor of M2 Pro / M3 Pro overall capability) only in a fairly small and specific subset of GPU applications. In particular, it's pretty much the matter of fact that that extra bandwidth achieves nothing in CPU-bound applications. It's also a matter of fact that only some of the GPU applications benefit, I just can not attest to exactly how big (or rather, small) and important that subset is.

With every new process node nowadays the following happens:

1. The cost per unit of area increases substantially. Decades ago the cost per unit of area was practically staying the same, resulting in 2x smaller node being 2x cheaper for the same design as the same design would take up 2x less area. Not anymore. The cost per unit of area is higher, therefore, if a portion of the design doesn't shrink much, it's actually more expensive on newer node. It takes a large shrink for the design to get cheaper or even merely stay the same in per-unit manufacturing cost.

2. IO shrinks very little. 4nm -> 3nm resulted in only 10% IO shrink. 1.25x SRAM, and 1.7x logic.

3. DRAM bandwidth is just a product of bus width * DRAM frequency, where bus width is really just a number-of-DRAM-controllers * 32.

4. DRAM controllers is IO. It barely shrinks in area going 4nm -> 3nm. But 3nm is more expensive per unit of area to manufacture. Therefore, DRAM controllers of the same design and the same count and the same bandwidth cost more money now on 3nm.

Most likely, that very marginal and situational performance benefit in a subset of GPU applications that M2 Pro saw going from 150 GB/s to 200 GB/s was still large enough to justify the relatively low (on 5nm) cost of 8 DRAM controllers (in traditional 32-bit-bus-per-controller terms). On M3 Pro that performance gain probably just dropped below the threshold and became unjustifiable against the increased cost of DRAM controllers, and the number of DRAM controllers was reduced to 6.

They will compare to the generation of products that yields the largest expected number of potential buyers.

The largest expected number of potential buyers equals "the probability of upgrading when properly advertised to" * (multiplied by) "the total number of macOS users currently owning the hardware of the generation in question".

Where "the probability of upgrading when properly advertised to" depends on how big the jump is, not only in performance, but cumulatively with every other change made to the product. It also depends on how old it is as people are more likely to make another expensive purchase if the previous one was long time ago, just distributing financial burden over time.

And where "the total number of macOS users currently owning the hardware of the generation in question" is merely measured as Apple has direct access to those statistics at any time.

For instance, perhaps the probability that an M2 user will upgrade is only 10%, given how recently M2 released, and how small the difference between M2 based products (as a whole, not just performance of the SoC) and M3 based products is. And perhaps there is 10 million of M2 users. Expected number of potential buyers is 10M * 0.1 = 1M.

Then perhaps the probability that an M1 user will upgrade is 30%. And perhaps there is 20 million of M1 users. Expected number of potential buyers is 20M * 0.3 = 6M.

Then perhaps the probability that an Intel user will upgrade is 40%. And perhaps there is only 10M of Intel users. Expected number of potential buyers is 10M * 0.4 = 4M.

Therefore: most focus is given to comparing to M1. Second tier amount of focus (only mention in speech occasionally, and show on charts) is given to comparisons with Intel. And third tier amount of focus is given to comparisons with M2 (never mention in speech, but do show on charts). Give 0 focus to anything else to keep the total amount of information presented manageable and avoid getting negative results by confusing and overloading people.

There is nothing malicious here. Just practicality which in this case, dare I say, benefits not only Apple themselves, but their users as well: those who are most likely to feel the need to upgrade as is will receive the most direct and clear information on what they will get out of it.

Short answer: yes.

Long answer:

If the hypothesis of the parent comment is correct, then the following should be true: joining shader logic paths or parts with very different resource usage, notably register usage, shall no more cause occupancy issues which on traditional architectures could be sometimes resolved by artificially splitting the logic into multiple different kernels with the sole purpose of making it possible for low-resource usage portions of the logic to run with higher occupancy.

If the case, it is of course beneficial not only because such splitting burns development hours (and can be potentially error prone), but also because such splitting introduces overhead of its own, for reasons anywhere from having to repeat some of the calculations in more than one separate kernel (instead of reusing the results) through having to store and subsequently reload intermediate values to communicate between parts, to having to pay the overhead of launching and synchronizing additional kernels.

It stands to reason, however, this is not going to help in those cases when it's not the occupancy that's the problem, but rather sparse SIMD/wavefront utilization of ALU resources is: in cases when the control flow is sub-wavefront divergent, but splitting the code into multiple kernel launches allows for compactification of SIMDs/wavefronts.

Furthermore, the joined shader might still fall a little bit short of expectations anyway because joining code together not always results in the compiler successfully identifying and eliminating redundant or repeated calculations, and/or allocating resources better due to having access to the entire program at once. It's usually the case, but occasionally the opposite happens - sometimes joined code results in compiler's optimizations taking a different path and producing code that is actually worse than it would have been if different parts of the code were compiled separately. The risk of that increases if the frequency with which the shader execution takes specific paths in the program is unusual (statistically not typical where statistics are taken over the whole world of programs across space and time :-) ) and the compiler ends up mispredicting which paths are low- and high-probability.

https://forums.macrumors.com/threads/ok-how-big-a-deal-is-th... + https://forums.macrumors.com/threads/ok-how-big-a-deal-is-th...

sound very plausible, potentially spot on.

I hate meta. It always sucks.

I think there is a bit of an exaggeration in the previous comment.

Feature sizes decoupled from process node names mid-90s somewhat mildly, with transistor density remaining accurate to the naming. With introduction of FinFET transistors (2012, Intel 22nm), feature size and node naming truly decoupled completely, but node naming still remained largely true to transistor density.

Transistor density started drifting apart from the node naming only recently, and in part it has to do with ever increasing difference in transistor density and its rate of improvement in different parts of the design, especially between logic (shrinks the fastest), SRAM (used for various caches and even register files), and IO (like DRAM controllers, shrinks the slowest).

3nm is smaller than 5nm. It's just there is quite literally not a single meaningful distance measurement in a 3nm design that measures 3nm, just like there is nothing 5nm in a 5nm design - most features are much larger than that physically. Further, (5/3)^2 ~= 2.8 may suggest that this is a 2.8x increase in transistor density, which it absolutely isn't, it's just nobody wanted to name the node 3.5 to yield more accurate and very traditional 2x ratio ((5/3.5)^2 ~= 2). Furthermore, even 2x would be misleading, only logic density increase somewhat approaches that figure:

logic: 1.7x SRAM: 1.25x IO: 1.11x

As chips contain all of these components, overall external area (physical size of the entire finished chip) of real-world chips going from 5nm to 3nm is shrinking by about 1.3-1.4x or so, far cry from (very) old school 2x, never mind 2.8x that naming may suggest.

To make things even more complicated, the following is also true: long time ago the cost of the chip was practically proportional to its area almost regardless of the process node used, therefore, 2x smaller chip costed almost 2x less to produce. Not anymore. Now every new node is substantially more expensive per unit area to use, thus a smaller chip on a newer node ends up costing only marginally less - and in some instances, more - than a bigger (by area) chip on an older node.

This is wildly false, see https://www.reddit.com/r/buildapc/comments/143ugg4/comment/j... as a real world example of a gaming PC you can buy right now for $2,600 which is the top of the crop and an absolutely wild gaming machine that's vastly better at gaming than $5,000 M2 Ultra Mac Studio even if the comparisons are done only in games that actually work and work well on the Mac.

If you were after a comparable experience with the fastest Macs on Earth you could configure a PC that's another $1,000 cheaper than that ($1,600).

The post quoted did indeed nail it IMO.

But I don't think those who pulled the trigger on buying a whole PC in addition to Mac just to game are the audience here: those people clearly value PC gaming a lot, spending that kind of money and going through that much trouble having the necessary setup at home, taking space and time to build and maintain. Those who care that much won't be satisfied with the state of Mac gaming and continue owning those PCs.

It's for those who would like to play on Mac but currently don't play at all on anything because games they'd like to play don't work on the only performance computing device they have - that Mac.

The second category of people I'd like to add are those who were really on a fence between getting a Mac and a PC (probably laptop at this point, as laptops are sufficiently similar for such a fence to be realistic, desktop PC and desktop Mac are very different machines in comparison), could have gone either way, but would prefer a Mac slightly, but also wanted to play games - not enough to own 2 computers, but enough to begrudgingly choose a PC over a Mac just for that reason.

Those folks are likely to buy a Mac instead next time they buy a new computer, which is probably going to be years from now, for some - years from the point in time when gaming on Mac because actually accessible and good, not immediately on spot.