M4+ Chip Generation - Speculation Megathread [MERGED]

[mr_roboto]

Hi @mr_roboto. The main observations from the patent were that the bidirectional and Lane bundle formats provided reasonable leads on Apple’s approach.

But they don't! Apple's patent doesn't sound like that at all.

(What do you mean by "bidirectional"? If it's that concept where one lane transmits in both directions simultaneously, which I think you got from Eliyan marketing material, that isn't present in Apple's patent at all. It shows unidirectional signaling.)

BoW was the most progressive (Open) option when Apple was developing UltraFusion and as a template it fits. I expect Apple did whatever was necessary in getting it to market though.

Why do you think BoW, UMI, UCIe, or Eliyan have anything to do with what Apple did or will do with UltraFusion???

This is the fundamental problem with all your posts. You found a bunch of marketing copy and white papers in which companies unrelated to Apple describe and/or puff up what they're doing. Then, you started regurgitating a warped version of this material into the thread (warped because you understand it very poorly, so you introduce weird ideas whenever you try to describe the concepts in your own words). Then, you start asserting without evidence that these things must be part of Apple's future and/or present UltraFusion technology. But you haven't actually done the work to show any kind of link between these technologies and UltraFusion! And you keep ignoring everyone who points out that actually, these things don't seem like UF at all.

You've even posted evidence that disproves your own claims. I've been hinting at the problems with your attempt at estimating UF bump counts (today's hint, you still have a major overcounting problem). Another one is that the UF bridge die image and BoW slice layout images you've posted prove that UF is not based on BoW. Forget about signal counts, slice size, and all that stuff, you're just confusing yourself when you try to analyze at that level. Just look at the geometrical layout of the bumps.

 

[Confused-User]

MR just posted an article that claims that they're seeing evidence of a variety of M4 Macs coming out this fall. Mentioned without emphasis in the article, they all have either 16 or 32GB RAM.

I think this is a big deal. It strongly suggests that even the lowest-end model (an 8 CPU core M4, sigh) will come with a base of 16GB.

I've thought all along that this would be the case, due to the AI push, but sentiments here have been quite negative, with many people saying they'd consider it lucky if the base was bumped to 12GB. This suggests that that was too pessimistic. Time will tell but I'm feeling optimistic.

 

[thenewperson]

MR just posted an article that claims that they're seeing evidence of a variety of M4 Macs coming out this fall. Mentioned without emphasis in the article, they all have either 16 or 32GB RAM.

I think this is a big deal. It strongly suggests that even the lowest-end model (an 8 CPU core M4, sigh) will come with a base of 16GB.

I've thought all along that this would be the case, due to the AI push, but sentiments here have been quite negative, with many people saying they'd consider it lucky if the base was bumped to 12GB. This suggests that that was too pessimistic. Time will tell but I'm feeling optimistic.

Interesting. I’ve been on the side of only the M4 MBP will start at 16GB but the others will still be 8GB (or at best move to 12GB). If they do all genuinely start at 16GB that’d be great. I’m curious what they’ll do for storage as that’s what I expected to go up (to 512GB) this generation.

 

[DrWojtek]

Incoming: base price for all devices is bumped with $200. You’re gonna love it.

 

[tenthousandthings]

MR just posted an article that claims that they're seeing evidence of a variety of M4 Macs coming out this fall. Mentioned without emphasis in the article, they all have either 16 or 32GB RAM.

I think this is a big deal. It strongly suggests that even the lowest-end model (an 8 CPU core M4, sigh) will come with a base of 16GB.

I've thought all along that this would be the case, due to the AI push, but sentiments here have been quite negative, with many people saying they'd consider it lucky if the base was bumped to 12GB. This suggests that that was too pessimistic. Time will tell but I'm feeling optimistic.

This is likely the last opportunity to speculate about CPU/GPU core counts and memory bandwidth for the M4 Pro/Max. Notice how the order seems to reflect Apple's internal development roadmap, if not the actual launch schedule. For example, it shows the Pro Mac mini was developed alongside the Mac Studio. To see this same list arranged by model, see here.

Here are the M2 and M3 product identifiers:

M2

Mac14,2 :: M2 100 (8/8, 8/10) MacBook Air 13"

Mac14,3 :: M2 100 (8/10) Mac mini

Mac14,5 :: M2 Pro 200 (10/16, 12/19) MacBook Pro 14"
Mac14,6 :: M2 Pro 200 (12/19) MacBook Pro 16"

Mac14,7 :: M2 100 (8/10) MacBook Pro 13"

Mac14,8 :: M2 800 (24/60, 24/76) Ultra Mac Pro

Mac14,9 :: M2 Max 400 (12/30, 12/38) MacBook Pro 14"
Mac14,10 :: M2 Max 400 (12/30, 12/38) MacBook Pro 16"

Mac14,12 :: M2 Pro 200 (10/16) Mac mini
Mac14,13 :: M2 Max 400 (12/30, 12/38) Mac Studio
Mac14,14 :: M2 Ultra 800 (24/60, 24/76) Mac Studio

Mac14,15 :: M2 100 (8/10) MacBook Air 15"

M3

Mac15,3 :: M3 100 (8/10) MacBook Pro 14"

Mac15,4 :: M3 100 (8/8) iMac (Two ports)
Mac15,5 :: M3 100 (8/10) iMac (Four ports)

Mac15,6 :: M3 Pro 150 (11/14, 12/18) MacBook Pro 14"
Mac15,7 :: M3 Pro 150 (12/18) MacBook Pro 16"

Mac15,8 :: M3 Max 300 (14/30) MacBook Pro 14"
Mac15,9 :: M3 Max 300 (14/30) MacBook Pro 16"

Mac15,10 :: M3 Max 400 (16/40) MacBook Pro 14"
Mac15,11 :: M3 Max 400 (16/40) MacBook Pro 16"

Mac15,12 :: M3 100 (8/8, 8/10) MacBook Air 13"
Mac15,13 :: M3 100 (8/10) MacBook Air 15"

Here's my projections for M4 family (admittedly guesswork with regard to which identifier is which product, but you get the idea), based on the M4 iPad Pro and the two "leaks" in the developer betas. [Obviously, I think MacBook Air will skip M4.]

My guess is they are testing the 32GB M4 base configuration of the 14" (parallel to the current 16GB M3 base configuration), but they will still offer it with 16GB M4 (currently 8GB M3). I think Apple sees that as a downgrade from the base.

M4 (projected)

Mac16,1 :: M4 120 (8/8) iMac (Two ports)
Mac16,2 :: M4 120 (10/10) iMac (Four ports)

Mac16,3 :: M4 120 (10/10) MacBook Pro 14"

Mac16,5 :: M4 Pro MacBook Pro 14"
Mac16,6 :: M4 Pro MacBook Pro 16"

Mac16,7 :: M4 Max MacBook Pro 14"
Mac16,8 :: M4 Max MacBook Pro 16"

Mac16,9 :: M4 Ultra Mac Pro

Mac16,10 :: M4 120 (10/10) Mac mini
Mac16,11 :: M4 Pro Mac mini

Mac16,12 :: M4 Max Mac Studio
Mac16,13 :: M4 Ultra Mac Studio

At first glance, if it follows M2, then it looks like they might give M4 Pro 240 GB/s memory bandwidth, M4 Max 480 GB/s, and thus M4 Ultra 960 GB/s...

 

[name99]

MR just posted an article that claims that they're seeing evidence of a variety of M4 Macs coming out this fall. Mentioned without emphasis in the article, they all have either 16 or 32GB RAM.

I think this is a big deal. It strongly suggests that even the lowest-end model (an 8 CPU core M4, sigh) will come with a base of 16GB.

I've thought all along that this would be the case, due to the AI push, but sentiments here have been quite negative, with many people saying they'd consider it lucky if the base was bumped to 12GB. This suggests that that was too pessimistic. Time will tell but I'm feeling optimistic.

I, in contrast, think this is the USUAL MR model of wild extrapolation vastly beyond what's justified by the data...

 

[Populus]

Hey, I have a question if someone can answer it with a speculative -but based on actual knowledge of the technology- reply.

1) How far do you think we are from having LPDDR6? Maybe for the M5? M6?

2) Do you think it will come with a significant improvement in speed or bandwidth increase?

Thank you and, as always, I appreciate politeness in the replies.

 

[treehuggerpro]

You keep coming up with PHYs with SerDes and saying that they are a basis for or the next generation of UF.

Why?

Hi Confused. This is a worn out (overly animated) subject, so I’m making this the last. The constant theme has been lower costs, higher yields and faster manufacturing, both in articles and Apple’s patent.

The BoW (Bunch of Wires) proposal was aimed at providing an approach that would also work with lower costing RDL packaging:

Multi-Chiplet system-in-package designs have recently received a lot of attention as a mechanism to combat high SoC design costs and to economically manufacture large ASICs. Multi-Chiplet designs require low-power area-efficient inter-Chiplet communication. Current technologies either extend on-chip high-wire count buses using silicon interposers or off-package serial buses over organic substrates. The former approach leads to expensive packaging. The latter to complex design. We propose a simple Bunch of Wires (BoW) interface that combines the ease of development of parallel interfaces with the low cost of organic substrates.

The No “low level communication circuitry" (physical layer PHY) conclusion, or direct connect binary hypothesis, is one reading. Another way to read these sections from Apple’s patent . . .

[0020] In one aspect it, has been observed that for large MCMs, accommodating die-to-die routing between a large number of dies becomes more difficult to support due to limited wiring line space and via pad pitch in the MCM routing substate. This can force lower wiring counts and require higher data rates to achieve a target bandwidth. These higher data rates in turn may require more silicon area for the dies, larger shoreline to accommodate input/output (I/O) regions and physical interface (PHY) regions (e.g. PHY analog and PHY digital controller), more power, and higher speed Serializers/Deserializers (SerDes) among other scalability challenges.

[0021] In accordance with embodiments routing arrangements are described in which significant wiring count gains can be obtained, allowing the data rate to be lowered, thereby improving signal integrity, reducing energy requirements, and a potential reduction in total area. In accordance with embodiments, bandwidth requirements may be met by expanding die-to-die placement for logic dies, which would appear counter-intuitive since increased distance can increase signal integrity losses. However, the expanded die-to-die placement in accordance with embodiments can provide for additional signal routing, thus lowering necessary raw bandwidth. Additionally, signal integrity may be preserved by including the main long routing lines (wiring) in a single dedicated metal routing layer, while shorter signal routes between neighboring dies can use two or more metal routing layers. The additional signal routing can be achieved in multiple metal routing layers, which can also allow for finer wiring width (W), spacing (S) and pitch (P), as well as smaller via size. Furthermore, the routing substrates in accordance with embodiments can be formed using thin film deposition, plating and polishing techniques to achieve finer wiring and smoother metal routing layers compared to traditional MCM substrates. In accordance with embodiments additional signal routing requirements can also be met using a die-last MCM packaging sequence. In a die-first packaging sequence the dies can be first molded in a molding compound layer followed by the formation of the routing substrate directly on the molded dies. In one aspect, it has been observed that a die-first packaging sequence can be accompanied by yield limits to the number of metal routing layers that can be formed in the routing substrate. In a die-last packaging sequence a routing substrate can be pre-formed followed by the mounting of dies onto the pre-formed routing substrate, for example by flip chip bonding. It has been additionally observed that a die-last packaging sequence may allow for the combination of known good dies with a known good routing substrate with a greater number of metal routing layers, facilitating additional wiring gain counts.

. . . is that they have been working with the alternate Open standard / protocol (of the day) in pursuing lower costing RDL substrates (over Silicon Interposers or to use both) from the beginning. And that their solution, "significant wiring count gains" "allowing the data rate to be lowered" was Apple following the BoW Specification.

2.4. Impact

The BoW specification provides several key advantages for chiplet-based systems:

• Can be implemented in legacy as well as state-of-the-art technologies (process nodes)
• Can be implemented in any packaging technology while retaining a single logical definition
• Provides design/implementation flexibility while retaining interoperability, allowing chiplet interfaces to be optimized for a given product/application

Compared to SerDes, BoW uses a lower data rate/wire so it requires more wires. However the lower data rates allow use of single-ended signaling and denser wire packing. In addition, in laminates, BoW can take advantage of multiple wiring layers and in advanced packaging it can take advantage of the much-increased wire density.

TSMC's (in development) CoWoS-R also follows the same objectives.

OCP's 2024 Summit has just happened, new videos will get posted in the weeks ahead. There's a few videos in last year’s chiplet focused talks if you're genuinely interested, but these predate previous links. The first of these on BoW, has some relevant observations about its current usage, the second is Marvell and Eliyan with an early presentation, and the third is the more recent video already posted.

ODSA's Bunch of Wires (BoW) PHY for Die Disaggregation Applications

Getting Moore with Less: How Chiplets and Open Interconnect Accelerate Cloud-Optimized AI Silicon

SEMICON Korea 2024 [Keynote Speech] - Eliyan

-------------

For die-to-die PHY basics, this was lifted from an independent blog by Kiran Bulusu of Intel. Similar and more detailed pages are easily found at many commercial sites.

Die-to-Die PHY (Physical Layer) refers to the physical interface or communication layer that enables connecting and transmitting signals between semiconductor dies in a multi-chip system. It encompasses the electrical and physical aspects of the interconnects between the dies.

Die-to-Die PHY handles the signaling, voltage levels, timing, and synchronization between the dies. It ensures reliable and efficient data transfer between the dies, considering data rates, power consumption, signal integrity, and noise immunity.

Die-to-Die PHY implementations can vary depending on the specific technology and standard used. Some of the key aspects and features of Die-to-Die PHY include:

• Signaling Technology: The choice of signaling technology impacts the interconnects’ data rates, power efficiency, and noise immunity. Standard signaling technologies used in Die-to-Die PHY include single-ended signaling, differential signaling (such as LVDS or PAM-4), and emerging high-speed serial interfaces like PCIe (Peripheral Component Interconnect Express) or CCIX (Cache Coherent Interconnect for Accelerators).

• Voltage Levels: Die-to-Die PHY defines the voltage levels and signaling schemes that transmit and receive signals between the dies. It ensures compatibility and proper voltage translation between different functional units, such as memory dies, processor dies, or accelerators.

• Timing and Synchronization: Die-to-Die PHY handles the timing and synchronization aspects of the interconnects to ensure data integrity and reliable communication. It may include clock distribution mechanisms, clock recovery circuits, and techniques for managing skew and latency.

• Noise Immunity and Signal Integrity: Die-to-Die PHY incorporates measures to mitigate noise and ensure signal integrity. This includes techniques like equalization, error detection, and error correction coding to compensate for signal degradation, crosstalk, and other noise sources.

• The implementation of Die-to-Die PHY can vary based on the specific technology and standard used, such as EMIB, interposer-based approaches, or organic substrate-based approaches. Each technology may have its own specific PHY specifications, considering the interconnects’ characteristics and requirements.

Die-to-Die PHY is crucial in enabling efficient and reliable communication between semiconductor dies, contributing to multi-chip systems’ overall performance, power efficiency, and functionality.

PS: BoW was a usable specification prior to becoming a Standard in July 2022. The “protocol (of the day)” separation was just a way to reference the prior period. The context being Apple’s M1 Ultra debuted in March 2022.

Unlike UCIe, OCP’s specification is truly Open with a design philosophy to match. BoW has no governance or implementation controls. Usage and how the specification is implemented are entirely up to the end user and their brief.

 

[caribbeanblue]

To me it's more of a reasonable speed than a likely speed, but yeah, it wouldn't be weird if it was that slow. It fits Apple's observable design philosophy: they like to build big/wide designs that run at relatively low clock speeds because that often results greater power efficiency. They are willing to accept the tradeoff that comes with this, reduced areal efficiency.

You can see this most clearly in their GPUs, which have worse perf/mm^2 than NVidia GPUs, because they're clocked far slower, but offer substantially better perf/W. This is also their CPU design philosophy, and it would not be surprising to see it applied to the interconnect fabric too.

Agree with all of it, but TechInsights mentioned that Apple has switched to TSMC's high performance cell library for the P-cores on the M4. Prior to the M4 their strategy has been both using high density cell libraries AND using a lot of area to squeeze in as much logic into their chips as possible. Now it seems like they think that some areas of the chip, like the P-cores, need increased frequency more than increasing the performance by doing other things like adding in more logic, which is interesting as it's more similar to the strategy others in the industry have been pursuing for years (Intel, AMD, etc). They still use high density libraries for the E-cores and GPU cores and other areas of the chip.
I know that increasing the efficiency also drives the performance higher, and probably to a higher extent than relaxing the gate pitch to hit higher clocks, but I suppose that depends on what aspect of the chip or cores they want to see improved most.

 

[Confused-User]

Interesting. I’ve been on the side of only the M4 MBP will start at 16GB but the others will still be 8GB (or at best move to 12GB). If they do all genuinely start at 16GB that’d be great. I’m curious what they’ll do for storage as that’s what I expected to go up (to 512GB) this generation.

I don't know why you'd think that. 256GB is plenty for people who have little local storage needs, because they live a cloud lifestyle. There's enough of those people (along with those who just don't need that much - they just do email and light web browsing) that a 256GB model remains useful, likely for years to come.

With RAM, however, the equivalent argument about 8GB now fails, given the coming ubiquity of AI. So it makes sense to see them bump base RAM, but less to base storage.

Of course I'd love to see them do both but I don't expect it.

Incoming: base price for all devices is bumped with $200. You’re gonna love it.

Never. Price increases for Apple product lines are as rare as unicorns. Virtually always, they only come with really major tech changes - the iPPM4 being a good example.

I, in contrast, think this is the USUAL MR model of wild extrapolation vastly beyond what's justified by the data...

Quite possible. Maybe Apple only tests high-end-RAM models in-house? ...nah, they're not that dumb. You're still right, this isn't enough to draw a conclusion. But it's enough to change the betting odds!

 

[leman]

. . . is that they have been working with the alternate Open standard / protocol (of the day) in pursuing lower costing RDL substrates (over Silicon Interposers or to use both) from the beginning. And that their solution, "significant wiring count gains" "allowing the data rate to be lowered" was Apple following the BoW Specification.

How would Apple adopting a third-party protocol help them lower the production costs? I thought that the main point of these standards was to simplify vendor interoperability. It seems to me that developing their own protocol and packaging method that is tailored to their specific use case would be the most advantageous way to go for a company like Apple.

 

[thenewperson]

I don't know why you'd think that.

Simple: Apple used 8/512 on the 14” MBP and it seemed to me they’d move to 16GB. So they’d just go with the same 8/512 on other M4 Macs was my thought process.

I do agree that 16/256 is more useful than 8/512, I just didn’t see Apple doing that given the 14” MBP.

 

[MayaUser]

Incoming: base price for all devices is bumped with $200. You’re gonna love it.

thats the thing..if this will come true..then nothing has changed...just some people now will complain about the price increase. But in general they increase the price with all new design and some big upgrades, so expect maybe next year with new design, new display tech

 

[ChrisA]

Assuming a 19.5 month refresh cycle

- M1: Q4 2020 5nm
- M2: Q3 2022 5nm
- M3: Q1 2024 3nm (N3)
- M4: Q4 2025 2nm (N2)
- M5: Q2 2027 1.4nm (A14)
- M6: Q4 2028 1.4nm (A14)
- M7: Q3 2030 1nm (A10)
- M8: Q2 2032 0.7nm (A7)
- M9: Q4 2033 0.5nm (A5)
- M10: Q3 2035 0.3nm (A3)

No, you have it all wrong. It will go like this...

- M1: Q4 2020 5nm
- M2: Q3 2022 5nm
- M3: Q1 2024 3nm
- M4: Q4 2025 2nm
- M5: Q2 2027 1.0nm
- M6: Q4 2028 0.0nm
- M7: Q3 2030 -1.0nm
- M8: Q2 2032 -2.0nm
- M9: Q4 2033 -3.0nm
- M10: Q3 2035 -5.0nm

The turning point is the M6 which is infinitely fast and uses zero power. After that point starting with M7, calculations finish before they start and the CPU generates power in the process.

Do you think this is impossible? Maybe, but so is going much below 1.0 nm. A silicon atom is about 0.2nm across. I seriously doubt we will ever see feature size less than a few atoms across. Even if the marketing people call it "1nm" it will be about 3 nm.

The days of just shrinking the size are reaching an end. Atoms are real and have a nominal size.

What will be fun is to see what they do after reaching the bottom physical limit of feature size. They will likey move to including different kinds of non-CPU cores. The NPU is the big thing for running 2020s vintage AI. We might see RAM and NPU specs climb through the roof by the 2030s before AI moves to quantum computers (in data centers) in the 2040s.

We can only guess about the future but one thing is sure, physics will always limit what technology can do. I don't think we will ever see future sizes that are smaller than single atoms.

 

[Confused-User]

Do you think this is impossible? Maybe, but so is going much below 1.0 nm. A silicon atom is about 0.2nm across. I seriously doubt we will ever see feature size less than a few atoms across. Even if the marketing people call it "1nm" it will be about 3 nm.

The days of just shrinking the size are reaching an end. Atoms are real and have a nominal size.

That's true, but you're missing the fact that nothing meaningful in current "3nm" chips is actually 3nm. And the equivalent has been true in previous generations for quite a few years.

There are a bunch more generations to go before we get close to hitting limits due to the physical size of atoms, and other physical limits that may limit us first.

What will be fun is to see what they do after reaching the bottom physical limit of feature size. They will likey move to including different kinds of non-CPU cores. The NPU is the big thing for running 2020s vintage AI. We might see RAM and NPU specs climb through the roof by the 2030s before AI moves to quantum computers (in data centers) in the 2040s.

True, special-purpose silicon is already a major part of modern chips, and not just NPUs. DSPs, media en/decoders, etc.

My bet is that we'll start to see more in/near-memory processing. You can already see small tentative steps in that direction with enterprise vendors selling memory modules with on-DIMM ARM cores, but that's not in- and only slightly near-memory. You can do *so much better* with the real thing. But doing it is VERY VERY hard, because there is no established paradigm for handling it in the OS, and the security model is almost completely new. (I don't mean nothing's ever been done about this, but there is as far as I know no well-understood best practice for it so far.)

Gains from going all-in on this could be extremely significant. In some cases, an order of magnitude or more. That's because memory latency and bandwidth is the #1 issue all CPUs face these days. Even small gains there can be significant, and the gains to be had here are often not small at all.

EDIT to add: Apple is almost uniquely well-situated to benefit from this. All the claims you normally hear about them benefiting from controlling the whole stack (hardware + software) are 90% BS- their hardware is fast because it's fast, not because of some software magic. BUT-- When it comes to new technology that requires extensive modification to software to be usable, then that benefit is real and meaningful. To get in-memory processing going on the Windows side, you would at a minimum need cooperation between Intel/AMD, Microsoft, and memory vendors, for a large and expensive multi-year project. Good luck with that! Intel couldn't even pull it off convincingly for crosspoint, where they didn't need memory vendors or AMD and the OS exposure was much lower. Perhaps IBM can manage it for POWER and Z.

This sort of big change is the kind of thing Apple tends to do really well. Build the hardware, ship it, and keep refining it in further generations, while slowly over several years introducing the software changes you need to take advantage of it. That's exactly what they've done with AI, for example.

We can only guess about the future but one thing is sure, physics will always limit what technology can do. I don't think we will ever see future sizes that are smaller than single atoms.

"Never" is a long time, but certainly that's likely to be true for the foreseeable future.

 

[PaulD-UK]

Quote: "...big change is the kind of thing Apple tends to do really well. Build the hardware, ship it, and keep refining it in further generations, while slowly over several years introducing the software changes you need to take advantage of it."

Apple has a huge capacity to disappoint.

The 2003 G5 Towers were heralded as '64 bit computing has arrived'.

To quote Phil Schiller, "The computers of the future will use 64 bit, but the future is now at Apple."
2003 G5 Macs marketing at introdiction

But it wasn't until Catalina in 2019 that 32 bit left...
Only 16 years.

 

[leman]

Quote: "...big change is the kind of thing Apple tends to do really well. Build the hardware, ship it, and keep refining it in further generations, while slowly over several years introducing the software changes you need to take advantage of it."

Apple has a huge capacity to disappoint.

The 2003 G5 Towers were heralded as '64 bit computing has arrived'.

To quote Phil Schiller, "The computers of the future will use 64 bit, but the future is now at Apple."
2003 G5 Macs marketing at introdiction

But it wasn't until Catalina in 2019 that 32 bit left...
Only 16 years.

You certainly picked an odd example to argue your point. MacOS still remains the only OS that did the 64-bit transition well.

 

[PaulD-UK]

Not arguing 'a point'.
Arguing a 'disappoint'.
Everyone else but Apple even more so.

 

[Confused-User]

Not arguing 'a point'.
Arguing a 'disappoint'.
Everyone else but Apple even more so.

It's a bizarre and deceptive argument to make. When they *got rid of 32-bit* is uninteresting, unless you have old software that no longer runs. It's when 64-bit code started working that matters, and Apple was very very early with that. The transition was nearly seamless, far better than on other platforms.

They can certainly suck some times. They are slowly murdering iTunes/Music. It's pretty much lost its hold on DJs because starting a few years ago it suddenly can't be relied upon to play music without glitches. That whole team really ought to be fired. Similarly, Apple Mail is a rolling train wreck. I filed ten issues with Apple and have many more but I gave up because it's like shouting into a well. (These are all things that worked perfectly at one time, which they then broke.)

But neither these examples, nor yours, have anything to do with what I was talking about.

 

[Basic75]

Apple has a huge capacity to disappoint.

To quote Phil Schiller, "The computers of the future will use 64 bit, but the future is now at Apple."
2003 G5 Macs marketing at introdiction

But it wasn't until Catalina in 2019 that 32 bit left...

If you want to criticise Apple for the marketing of the 64bit transition you should point out that what they released in 2003 was half-assed. First they would have a 32bit-everything system on a 64bit processor, later they started supporting 64bit CLI apps. Only with Leopard a few more years later did Mac OS X support 64bit applications with a (native) GUI, and that was still on a 32bit kernel. The jump to a full 64bit system took even longer. Supporting a 32bit userland for many more years is normal. That was never the problem. On the contrary, with many developers never providing a 64bit build of their applications (and games!) a lot of users would have wanted even longer 32bit support.

 

[name99]

That's true, but you're missing the fact that nothing meaningful in current "3nm" chips is actually 3nm. And the equivalent has been true in previous generations for quite a few years.

There are a bunch more generations to go before we get close to hitting limits due to the physical size of atoms, and other physical limits that may limit us first.


True, special-purpose silicon is already a major part of modern chips, and not just NPUs. DSPs, media en/decoders, etc.

My bet is that we'll start to see more in/near-memory processing. You can already see small tentative steps in that direction with enterprise vendors selling memory modules with on-DIMM ARM cores, but that's not in- and only slightly near-memory. You can do *so much better* with the real thing. But doing it is VERY VERY hard, because there is no established paradigm for handling it in the OS, and the security model is almost completely new. (I don't mean nothing's ever been done about this, but there is as far as I know no well-understood best practice for it so far.)

Gains from going all-in on this could be extremely significant. In some cases, an order of magnitude or more. That's because memory latency and bandwidth is the #1 issue all CPUs face these days. Even small gains there can be significant, and the gains to be had here are often not small at all.

EDIT to add: Apple is almost uniquely well-situated to benefit from this. All the claims you normally hear about them benefiting from controlling the whole stack (hardware + software) are 90% BS- their hardware is fast because it's fast, not because of some software magic. BUT-- When it comes to new technology that requires extensive modification to software to be usable, then that benefit is real and meaningful. To get in-memory processing going on the Windows side, you would at a minimum need cooperation between Intel/AMD, Microsoft, and memory vendors, for a large and expensive multi-year project. Good luck with that! Intel couldn't even pull it off convincingly for crosspoint, where they didn't need memory vendors or AMD and the OS exposure was much lower. Perhaps IBM can manage it for POWER and Z.

This sort of big change is the kind of thing Apple tends to do really well. Build the hardware, ship it, and keep refining it in further generations, while slowly over several years introducing the software changes you need to take advantage of it. That's exactly what they've done with AI, for example.


"Never" is a long time, but certainly that's likely to be true for the foreseeable future.

There are other versions of this point possible. Consider, for example, file storage. The standard file storage primitives, for decades, have been seek to block, read block, write block; with everything else (eg file systems and databases) built on these.
But with SSDs alternative primitives are possible, in particular some sort of "atomically write this set of blocks" primitive. The reason this is possible is that SSDs intrinsically provide journaling as part of the FTL, and you can exploit that, rather than doing a SECOND level of journaling at the file system or database level.

Right now this is only academic (though it looks very promising); but once again it's the kind of thing where Apple can feasibly implement it (at least for their internal storage; obviously external drives present an additional problem) by appropriate modifications all the way from API and file system design down to the SSD controller in a way that's difficult for anyone else (apart from IBM...)

 

[Confused-User]

There are other versions of this point possible. Consider, for example, file storage. The standard file storage primitives, for decades, have been seek to block, read block, write block; with everything else (eg file systems and databases) built on these.
But with SSDs alternative primitives are possible, in particular some sort of "atomically write this set of blocks" primitive. The reason this is possible is that SSDs intrinsically provide journaling as part of the FTL, and you can exploit that, rather than doing a SECOND level of journaling at the file system or database level.

Right now this is only academic (though it looks very promising); but once again it's the kind of thing where Apple can feasibly implement it (at least for their internal storage; obviously external drives present an additional problem) by appropriate modifications all the way from API and file system design down to the SSD controller in a way that's difficult for anyone else (apart from IBM...)

It's not at all clear to me that the benefits to be had from rethinking filesystems are nearly as broadly useful. AFAIK, the two paradigms in significant current use, besides tree-structured filesystems, are key-value stores and object stores. Neither of them is likely to be broadly useful to Apple's customer base. What about some other paradigm? I suppose it's possible, but I don't know what it would be.

As for multi-block atomic writes, yes, those can be really useful. (Didn't partial support for that get merged into Linux recently?) But it's probably going to be transparent to most software. Surely, if you expose an interface for it, some code will see big benefits (some DBMSes, for example), but again, I don't think it's broadly useful. Am I missing something?

 

[name99]

It's not at all clear to me that the benefits to be had from rethinking filesystems are nearly as broadly useful. AFAIK, the two paradigms in significant current use, besides tree-structured filesystems, are key-value stores and object stores. Neither of them is likely to be broadly useful to Apple's customer base. What about some other paradigm? I suppose it's possible, but I don't know what it would be.

As for multi-block atomic writes, yes, those can be really useful. (Didn't partial support for that get merged into Linux recently?) But it's probably going to be transparent to most software. Surely, if you expose an interface for it, some code will see big benefits (some DBMSes, for example), but again, I don't think it's broadly useful. Am I missing something?

What I described is not a REPLACEMENT for the file system; it's a way to make the existing file system faster and more energy efficient by not writing a second journal; rather recovery (when necessary) can exploit the journal that's already being written by the FTL.

 

[Confused-User]

What I described is not a REPLACEMENT for the file system; it's a way to make the existing file system faster and more energy efficient by not writing a second journal; rather recovery (when necessary) can exploit the journal that's already being written by the FTL.

Oh, I see. I knew this; my confusion comes from me talking about major changes that permeate the system but require large changes in both hardware and software. When you brought up the FS stuff I thought you were talking about something analogous.

So, yes, I think what you're talking about is pretty much a no-brainer, eventually. Honestly I'm a little surprised there isn't movement on it already in the broader industry. (Which would happen... where? T10?) Apple could indeed do it sooner, but it's not clear to me that it's worth that much effort if the rest of the industry will shortly be doing the same thing.

 

[tenthousandthings]

Well, in a couple of days we'll know more about the N3E (M4) generation of Apple Silicon. Specifically, whether or not they are going to have an A18 and A18 Pro, and what that will mean for memory bandwidth, core counts, and so on.

I've spent some time cleaning up, correcting, and expanding my two posts on the Mac identifiers, because I think the decision to change the approach to Mac identifiers (which began with the last new product of the transitional N5 (M1) generation, the Mac Studio, Mac13,1 and Mac13,2) is an important change and provides useful information, albeit largely in retrospect. Making predictions from it remains a fool's game, but we are all fools here.

The two posts are here: listed by model in #32 of the @Jamie I identifiers thread, and listed in numerical order in #905 above in this here M4 speculation thread. The primary sources used are Apple's "How to identify your [product name] model" specs, the M4 iPad Pro specs, and the two leaks from the Sequoia developer betas. [Note: I still maintain that the first is not a leak, but rather information Apple was willing to expose, but that's just a guess. The second one, too, may also be purposeful, but again, only a guess. I don't assume either.]

You'll see I think the order does appear to reflect some kind of internal Apple product-development timeline/roadmap. So the 2019 Mac Pro chassis got the M2 Ultra first, having been dropped in the M1 generation. Hopefully, someday, before I die, the story of Jade 4C-die and the M1 Extreme [?] will be told. Keep in mind that early testing of the M2 Ultra may have begun before the M1 Ultra (and the new identifier system) was launched in the Mac Studio (March 2022). N5P (M2) went into volume production in "2021" (not "second half 2021"), and while it's reading past tea leaves, it seems a safe bet to say this.

The other thing that jumped out as I added the GB/s memory bandwidth numbers was the choice of 120 GB/s for the M4 base seemed to point toward a neat 120-240-480-960 progression in the M4 family.