Why Intel and AMD don't make chips like the M2 Max and M2 Ultra

[Muziekschuur]

I disagree on the last alinea. The rest fits like a glove. They last quite a long time. (At least the Power Mac line did (and probably does). Their style and quality means they hardly go out of fashion. While the black windows boxes do.

They are allso build for easy expansion. I hope the next M3 Mac Pro is modulair again, on memory and harddisks and has at least 3 pci-e slots.

 

[Muziekschuur]

The fun part is... 'right to repair' ... we'll see where that takes us. I bet there are people out there right now soldering memory slots on the places where soldered memory is attached right now.

 

[Joe Dohn]

I don’t even know how well Macs can run things like MatLab, Simula, CAN adapters or any of the proprietary software that the companies that build the simulators have.

Macs are less versatile than ever, but they CAN run Mathlab: https://www.mathworks.com/support/requirements/matlab-mac.html

Hell, I wouldn’t bet on them being able to use serial ports.

That can be easily solved with a serial port to USB adapter:

And MacOS, as much as I love it, just can’t compete with Windows in terms of backwards compatibility. Which in an industry RIDDLED with legacy baggage is critical.

Agreed here. While I can understand that Apple doesn't want to keep the legacy compatibility built into the system, they could isolate the backwards compatibility as modules that can be installed or removed.

Microsoft has been doing just that lately with Windows. They've been cleaning up the core OS while isolating the legacy code in modules. They do have to move slowly, but they're doing that.

 

[dmccloud]

Macs are less versatile than ever, but they CAN run Mathlab: https://www.mathworks.com/support/requirements/matlab-mac.html



That can be easily solved with a serial port to USB adapter:

Agreed here. While I can understand that Apple doesn't want to keep the legacy compatibility built into the system, they could isolate the backwards compatibility as modules that can be installed or removed.

Microsoft has been doing just that lately with Windows. They've been cleaning up the core OS while isolating the legacy code in modules. They do have to move slowly, but they're doing that.

Apple actually couldn't do that given its long term roadmap. The reason 32-bit support was deprecated in Mac OS to begin with was in preparation for the move to Apple Silicon and an ARM-based ISA. Windows on ARM itself has some limitations related to 32 and 64-bit x86 code, and Microsoft has never even attempted to create a translation layer akin to Rosetta 2 that could handle some of those longstanding issues. Microsoft is also beholden to Qualcomm for production of the SQ(x) CPUs being used in the Surface Pro X, and those are variants on the Qualcomm flagship SOCs used in phones such as the Samsung Galaxy S22 and S23 series.

 

[bobcomer]

That can be easily solved with a serial port to USB adapter:

Is there a version with Mac AS compatibility?

 

[Muziekschuur]

Macs are less versatile than ever, but they CAN run Mathlab: https://www.mathworks.com/support/requirements/matlab-mac.html



That can be easily solved with a serial port to USB adapter:

Agreed here. While I can understand that Apple doesn't want to keep the legacy compatibility built into the system, they could isolate the backwards compatibility as modules that can be installed or removed.

Microsoft has been doing just that lately with Windows. They've been cleaning up the core OS while isolating the legacy code in modules. They do have to move slowly, but they're doing that.

In a Mac pro you can easily boot snow leopard and sonoma if you so please. Enough ways to store ssd's.

 

[Muziekschuur]

Thunderbolt & USB 3.2 will replace the need for pci-e slots. In the very very near future.

 

[deconstruct60]

Apple actually couldn't do that given its long term roadmap. The reason 32-bit support was deprecated in Mac OS to begin with was in preparation for the move to Apple Silicon and an ARM-based ISA. Windows on ARM itself has some limitations related to 32 and 64-bit x86 code, and Microsoft has never even attempted to create a translation layer akin to Rosetta 2 that could handle some of those longstanding issues.

The Rosetta 2 system doesn't really 'handle' the full 32 bit x86 code stack, it largely punts it. It handles some aspects of 32-bit era code but no macOS library 32 bit support means they tossed substantive work out the window. (WINE leverage the limited support but that effort (resource spend) is outsourced. )

Rosetta 2 doesn't do anything with mixed binaries ( plug-in in x86) and app in Arm. No kernel extensions ( so though says all 64-bit x86 instructions... mainly the userland ones. )

" ...

What Can’t Be Translated​

Rosetta can translate most Intel-based apps, including apps that contain just-in-time (JIT) compilers. However, Rosetta doesn’t translate the following executables:

• Kernel extensions
• Virtual Machine apps that virtualize x86_64 computer platforms

Rosetta translates all x86_64 instructions, but it doesn’t support the execution of some newer instruction sets and processor features, such as AVX, AVX2, and AVX512 vector instructions.
..."

About the Rosetta Translation Environment | Apple Developer Documentation

Learn how Rosetta translates executables, and understand what Rosetta can’t translate.

developer.apple.com

Modern Vector ... punt.

But apple didn't really want to support 32-bit Arm either. 32-bit Arm was purged from the iPhone/iPad OS also which had no x86 transition to make either. Apple dumped it everywhere ( even places that x86 didn't even remotely touch.). Decade old Apple Silicon devices get tossed on Vintage/Obselte on regular schedule also. Apple does incremental purges on a rolling basis.


Part of Windows on Arms problems is that Microsoft did spend tons of time and effort wandering in the weeds of legacy 32-bit x86 issues for a relatively long time.

Microsoft is also beholden to Qualcomm for production of the SQ(x) CPUs being used in the Surface Pro X, and those are variants on the Qualcomm flagship SOCs used in phones such as the Samsung Galaxy S22 and S23 series.

That isn't any more 'labored' an exercise since Microsoft also doesn't make x86 packages either. Intel's Thread Director for P/E cores ... Microsoft has to deal with. AMD's NUMA CCX core clusters in early Zen models .... Microsoft had to deal with. New AVX extension #42 ... Microsoft has to deal with.

The newer Snapdragon 8cx variants do not appear in phones. Variations on SD 7 or 'plain' 8 yes, but the CX is Windows targeted. The current Windows dev kit

“Project Volterra” review: Microsoft’s $600 Arm PC that almost doesn’t suck

There’s a reason it isn’t a Surface PC, but it’s good for its intended purpose.

arstechnica.com

is not a "Mac Mini killer" , but it is more than decent.

The major problem with Qualcomm is that they (and Microsoft ) had a very radio focused view. It wasn't that it was Arm core based, but that it had an 'Always on' connection to a celluar network for networking that was the major feature. In part , Qualcomm was interested in selling more radios than the PC itself.

 

[deconstruct60]

Thunderbolt & USB 3.2 will replace the need for pci-e slots. In the very very near future.

PCI-e v5 SSDs say no on 'replace'. Reduce need perhaps, but wholesale replace? No.

 

[Joe Dohn]

Is there a version with Mac AS compatibility?

The adapter itself should work out of the box with Apple Silicon or even an iPad, but the device compatibility depends on drivers, which will either have to be written by the manufacturer or someone else, depending on the device.

 

[theorist9]

And they didn't care. Form factor and silent operation are more important to Apple than peak, raw and overall performance.

Not quite. As someone who owns both a 2019 27" Retina iMac and a 2014 15" MacBook, I can tell you the Retina iMacs and Retina MacBook Pros are clear counterexamples to the part about noise. They can both get quite noisy when pushed. Thus, for those product lines, noise took a back seat to both form factor and performance. The irony is that the form factor of the iMac Pro is nearly identical to that of the 27" iMac, so they could have gotten quiet operation in the iMac's form factor, with little added expense, yet they did not.

It's not that they didn't care about noise. it's rather that Intel processors forced them to do the following, at least for their laptops: "Pick two of these: Performance, Form Factor, Noise", and the one that lost was noise. Apple Silicon allows them to have all three. Not ultimate performance, but close to ultimate performance (at least CPU performance) for a mobile device—and better true mobile performance (meaning on-battery) than perhaps any PC laptop.

 

[Joe Dohn]

Apple actually couldn't do that given its long term roadmap. The reason 32-bit support was deprecated in Mac OS to begin with was in preparation for the move to Apple Silicon and an ARM-based ISA. Windows on ARM itself has some limitations related to 32 and 64-bit x86 code, and Microsoft has never even attempted to create a translation layer akin to Rosetta 2 that could handle some of those longstanding issues. Microsoft is also beholden to Qualcomm for production of the SQ(x) CPUs being used in the Surface Pro X, and those are variants on the Qualcomm flagship SOCs used in phones such as the Samsung Galaxy S22 and S23 series.

They absolutely CAN do that. So much so that Apple has poured money on their games development kit, which runs Windows games. Apple went as far as adding DirectX support ahead of everyone.

Guess what Windows games usually are, by the way? That's right: they're usually 32-bit.

One thing they might fear is that people will cling to legacy 32-bit apps if they keep supporting that with virtualized layers. However, the lack of 32-bit support, as you can see, has absolutely hurt Apple's compatibility.

 

[theorist9]

I think Apple in the enterprise space as a whole is a non-starter.

In my experience as an electronics lab technician at a fortune 500 company, I don’t think Apple could even get off the ground.

I don’t even know how well Macs can run things like MatLab, Simula, CAN adapters or any of the proprietary software that the companies that build the simulators have.

Hell, I wouldn’t bet on them being able to use serial ports.

And MacOS, as much as I love it, just can’t compete with Windows in terms of backwards compatibility. Which in an industry RIDDLED with legacy baggage is critical.

And if you need a Unix-compatible system, the machines ship with Ubuntu.

And there’s the cost-sensitive issue that Dell, HP, Lenovo, etc. sells their hardware in bulk for dirt cheap to enterprises. Something that I have never heard Apple doing.

There’s also the factor of things like bulk discounts for Microsoft Office, Sharepoint, etc. Not even addressing how the Mac versions of Office are gimped compared to the Windows version.

I love my Mac, don’t get me wrong. Apple has done some amazing work with them lately. But they’re what I call an “individual user centric” experience. They’re really more for individual or small business creative types, or “prosumers” rather than enterprise types.

This is an interesting question. Agreed about the cost-sensitive part when it comes to hardware. One key point is that Windows text rendering allows it too look decent on lower-ppi (and thus much less costly) displays than MacOS, which I've found requires at least 4k@27" (160 ppi) to not be headache-inducing for extended text work.

But at the same time, you have companies like IBM deploying Macs and finding that, overall, they save money because they require much less IT support. Plus it improves employee satisfaction:

IBM and Jamf: Technology Choice Improves Performance and Satisfaction

Learn about the tremendous growth of IBM’s Apple deployment.

www.jamf.com

And other large high-tech companies, like Google, have lots of Macs.

So here's my (pure) speculation:

If you're a leading-edge tech company, Macs are fine because you have the sophistication to make them work. Plus you're probably more proactive about upgrading legacy software (reducing backwards-compatability issues), and you're also more likely to give your employees higher-end hardware to start with (reducing the hardware cost differential between Macs and PCs).

But if you're more of a lumbering dinosaur, Macs could be challenging. For instance, my university's IT dept. falls into this category, and saving files onto their servers with Macs works nowhere near as well as doing so from a PC. If I save a file from a PC over the VPN, it's a short delay (2-3 sec). But from a Mac, I just timed it, and it takes 9 sec (during which time you have to sit and wait, because you can't work on a file while it's being saved).

Having said all that, according to this, Mac enterprise use is growing:

2021 — the year Apple became a big player in enterprise tech

In a few years' time, when peering back through the coronavirus fog, we’ll fully understand that 2021 is the year Apple truly entered the enterprise.

www.computerworld.com

 

[wegster]

I think Apple in the enterprise space as a whole is a non-starter.

In my experience as an electronics lab technician at a fortune 500 company, I don’t think Apple could even get off the ground.

I don’t even know how well Macs can run things like MatLab, Simula, CAN adapters or any of the proprietary software that the companies that build the simulators have.

Yeah, we're thinking (and seeing) similarly. There has been a higher shift in people in IT and dev roles moving to Mac for 'a reasonable amount of time' but that's more one-off versus for example, moving 'standard set of laptop options' to Mac across a Fortune 100/500 company with thousands of users.

They've progressed, but not so sure RE: CAN adapters and the like. I had to do a bunch of connections to various embedded/SBC types of devices over the past couple of years, and that, at least, works much better than it used to when you'd have to fight to just get a working switch console connection and terminal to the point of proper connection.

Hell, I wouldn’t bet on them being able to use serial ports.

And MacOS, as much as I love it, just can’t compete with Windows in terms of backwards compatibility. Which in an industry RIDDLED with legacy baggage is critical.

And if you need a Unix-compatible system, the machines ship with Ubuntu.

Yep, Dell and others have also progressed on the server side and can get what you want, whether Ubuntu or RHEL, etc.

And there’s the cost-sensitive issue that Dell, HP, Lenovo, etc. sells their hardware in bulk for dirt cheap to enterprises. Something that I have never heard Apple doing.

There’s also the factor of things like bulk discounts for Microsoft Office, Sharepoint, etc. Not even addressing how the Mac versions of Office are gimped compared to the Windows version.

I'm so with you on the Office gimp-ness...partially MS but also some weirdness as well as proper calendar/caldav / Exchange integrations and the like. It sometimes seems like the 'Mac Office gimped' is reduced now and then but then I still run into it routinely - I think it's still impossible, for a single example of many, to embed a set of larger slides in a PPT into 'thumbnail view' on a single slide, that when in presentation mode, with cycle through full-screening the thumbnails in turn. Yeah, that's an 'odd' one, but heavily useful when doing product and technical training for a week... Outlook is of course, still worse.

I love my Mac, don’t get me wrong. Apple has done some amazing work with them lately. But they’re what I call an “individual user centric” experience. They’re really more for individual or small business creative types, or “prosumers” rather than enterprise types.

Some of the things have become more manageable - I did an internal 'how to Mac' writeup that was used at an F100 company, with everything from VPN and 'smart card' access on up, and it's generally gotten easier, but like we've both said, that's a far cry from management at scale of Macs across and enterprise.

 

[mr_roboto]

The only thing that makes the 68020 look "more CISCy" than x86 is the elaborate indirect addressing mode, which was as ill-considered as Intel's original idea of making the string operations one byte long. Even the BF ops have analogs in modern RISC processors. Claiming one architecture is more one or the other type is a fraught assertion.

These elaborate indirect modes actually pose more problems for high performance 680x0 than x86 variable length decode does for x86. This was one of several reasons why 68K started falling behind x86 in the late 1980s and early 1990s.

As John Mashey once wrote in a series of extremely insightful USENET posts about CISC vs RISC,

Even though various RISCs have made various decisions, most of them have been very careful to omit those things that CPU designers have found difficult and/or expensive to implement, and especially, things that are painful, for relatively little gain.

He then goes on with detailed analysis of the characteristics of a wide variety of CISC and RISC ISAs. His feature comparison table puts x86 not far from the RISC/CISC dividing line - that is, in many of the implementation complexity metrics which divide RISC from CISC, x86 is closer to RISC than other CISCs.

This was by accident. The 8086 wasn't intended to become the primary ISA of the entire computing market for the next 50 years, it was only supposed to keep Intel customers buying Intel CPUs while they worked on a longer term ISA project, the ill-fated iAPX 432. So the project was pretty limited - just deliver a better version of the already popular 8080 and 8085. Since those were pretty simple CISC ISAs, x86 inherited that simplicity, and didn't fall into some of the traps 68K did.

Another timeless and relevant Mashey quote from the same series of posts:

This can lead to the funny effect that a relatively "clean", orthogonal archiecture may actually be harder to make run fast than one that is less clean.

That's 68K vs x86 in a nutshell. 68K looks so clean and nice and wonderful. In the early 1980s, a programmer couldn't have been faulted for thinking it (or something like it) was the future and x86 was bad garbage, soon to be a distant memory. But 68K had a bunch of non programmer visible things lurking which meant it was going to have long term problems, and then Motorola took that stuff to the next level with the 68020.

 

[mr_roboto]

The Rosetta 2 system doesn't really 'handle' the full 32 bit x86 code stack, it largely punts it. It handles some aspects of 32-bit era code but no macOS library 32 bit support means they tossed substantive work out the window. (WINE leverage the limited support but that effort (resource spend) is outsourced. )

You're saying broadly true things but interpreting them in a very weird way. There are no limitations in Rosetta itself here. If Apple still shipped 32-bit macOS library code as part of macOS (Foundation, Cocoa, etc), Rosetta 2 could run 32-bit x86 Mac apps on Apple Silicon.

Rosetta 2 doesn't do anything with mixed binaries ( plug-in in x86) and app in Arm.

Yes, Rosetta 2 cannot mix Arm and x86 code in the same process, but a few years before the AS transition, Apple started encouraging developers to move from in-process to out-of-process plugins. Out-of-process has benefits unrelated to the Arm transition, but helped prepare for it: many native Arm apps can still use legacy x86 plugins, provided that the plugin was written to function out-of-process and not just in-process.

They absolutely CAN do that. So much so that Apple has poured money on their games development kit, which runs Windows games. Apple went as far as adding DirectX support ahead of everyone.

Guess what Windows games usually are, by the way? That's right: they're usually 32-bit.

As noted above, Rosetta 2 actually does support running 32-bit x86 binaries, provided that there's libraries available. When using WINE, WINE is the provider of Win32 libraries, not macOS. Since Codeweavers has enhanced WINE to perform 32-to-64 thunking emulation of Win32 libraries on 64-bit macOS, many 32-bit Windows games can run on Apple Silicon.

Apple's Game Porting Toolkit is roughly WINE plus their own D3D-to-Metal layer. They've been trying to position it as a way for game devs to investigate a true native port, because that's what Apple really wants, but it's looking like they're opening up enough that Codeweavers is now able to use Apple's D3DMetal (the original licensing terms wouldn't allow use of Apple's new stuff in commercial products). I expect Codeweavers to use this to provide a somewhat more polished and performant experience than Game Porting Toolkit for popular Windows games.

 

[thenewperson]

I expect Codeweavers to use this to provide a somewhat more polished and performant experience than Game Porting Toolkit for popular Windows games.

I believe their last update did exactly this

 

[MRMSFC]

Agreed here. While I can understand that Apple doesn't want to keep the legacy compatibility built into the system, they could isolate the backwards compatibility as modules that can be installed or removed.

I’ve heard the Mac version of MatLab isn’t up to snuff vs. the Windows version, but I have no proof.

I know USB to Serial exists, but as someone mentioned, there’s driver situation issue.

And while yeah, Apple could keep that legacy stuff, that just goes back to my point about the niche they fill. They focus heavily on the consumer/prosumer users, which don’t usually have thousands to millions of dollars wrapped up in legacy tools, software, etc. so there’s not much point in my opinion.

 

[leman]

Hell, I wouldn’t bet on them being able to use serial ports.

Apple actually fairly recently added native support for USB-to-Serial adapters, I used one last year to program my HDMI switch. Worked out of the box. Don’t remember the brand though.

But this doesn’t change the fact that you are right. Mac’s are the worst choice if it comes to legacy support, especially legacy software.

 

[bobcomer]

Apple actually fairly recently added native support for USB-to-Serial adapters, I used one last year to program my HDMI switch. Worked out of the box. Don’t remember the brand though.

That's good to hear! For some reason I've had more need of a serial port this year than probably the last 10 combined. While I usually will be using a Windows machine to do the work, it's nice to know one of my Macs could do it if needed.

 

[wegster]

Not quite. As someone who owns both a 2019 27" Retina iMac and a 2014 15" MacBook, I can tell you the Retina iMacs and Retina MacBook Pros are clear counterexamples to the part about noise. They can both get quite noisy when pushed. Thus, for those product lines, noise took a back seat to both form factor and performance. The irony is that the form factor of the iMac Pro is nearly identical to that of the 27" iMac, so they could have gotten quiet operation in the iMac's form factor, with little added expense, yet they did not.

It's not that they didn't care about noise. it's rather that Intel processors forced them to do the following, at least for their laptops: "Pick two of these: Performance, Form Factor, Noise", and the one that lost was noise. Apple Silicon allows them to have all three. Not ultimate performance, but close to ultimate performance (at least CPU performance) for a mobile device—and better true mobile performance (meaning on-battery) than perhaps any PC laptop.

Agreed. Both my 2011MBP and 2015MBP were jet engines once you simply plugged in an external display and <did work>. The 2015 was somewhat better, but both got to loud levels fairly easily. It was a somewhat disappointing pattern there for a while - those two at least, were generally decent systems overall (vs the 'lets lose ports, butterfly keyboard, make thinner 2016-2019 MBPs), but it was kind of embarrassing, and when the CEO or people who are technical but not Mac users are asking - 'huh, something wrong with your $ MacBook?', yeah, not a super compelling 'free advertisement' for others considering buying one.

I like the general direction of the AS MBPs, as in bringing back useful ports, MagSafe, and not pursuing thin-ness 'at all costs' (including thermals) but it seems like the MB Airs can induce thermal throttling, so I have concerns as the lineup goes forward. No issues so far on my M1 Max MBP14", but remain concerned looking ahead.

 

[mr_roboto]

I like the general direction of the AS MBPs, as in bringing back useful ports, MagSafe, and not pursuing thin-ness 'at all costs' (including thermals) but it seems like the MB Airs can induce thermal throttling, so I have concerns as the lineup goes forward. No issues so far on my M1 Max MBP14", but remain concerned looking ahead.

Have you ever used a M1 or M2 Air? They don't reduce clock speed unless you really push them. IIRC, in my experiments, the M1 Air would remain at full speed indefinitely with 2 P cores loaded, I had to bump it up to three or four cores at 100% to get it to throttle. And even when you do that, you get some time at full speed before it has to slow down. The rampdown is gradual and stops at about 2/3 of full speed, which is not bad.

For what most people want to use an Air for, Apple Silicon Airs are perfect. They never slow down under typical light and medium loads, have excellent battery life, and perform reasonably well even when asked to do much more than people expect an ultralight to be capable of.

It's not clear to me where your concern about AS is coming from. Intel Airs had very similar behaviors - they also reduced clock speed under high sustained loads. But they throttled much harder and had to spin up a very noisy and annoying fan even while throttled.

 

[wegster]

Have you ever used a M1 or M2 Air? They don't reduce clock speed unless you really push them. IIRC, in my experiments, the M1 Air would remain at full speed indefinitely with 2 P cores loaded, I had to bump it up to three or four cores at 100% to get it to throttle. And even when you do that, you get some time at full speed before it has to slow down. The rampdown is gradual and stops at about 2/3 of full speed, which is not bad.

For what most people want to use an Air for, Apple Silicon Airs are perfect. They never slow down under typical light and medium loads, have excellent battery life, and perform reasonably well even when asked to do much more than people expect an ultralight to be capable of.

It's not clear to me where your concern about AS is coming from. Intel Airs had very similar behaviors - they also reduced clock speed under high sustained loads. But they throttled much harder and had to spin up a very noisy and annoying fan even while throttled.

Not yet (AS Air) - I have an M1 Max 14” MBP 64GB - I’m kind of specced out of the Air for several reasons, but shifted my wife from MBPs to Air as both her compute needs are lower and she has a weird ‘power’ of somehow killing multiple MBPs. She’s still doing ok on the last Intel Air but will be due and probably going to an M2 Air soonish.

My main concern is that with the much lower AS power consumption, and thus heat, I was kind of surprised they are still throttling, which bode poorly if Apple leans back into the whole ‘we can do even thinner now’ across the lineup. I don’t have any strong reason to think this other than the serious disappointment of the 2016-2018/19 lineup. The move to 3nm variants will also reduce temps and power consumption, but of corse they can still come out on ‘the wrong side’ of the performance vs thermal/cooling equation. The years of trying to drive multiple displays even with dGPU Intel MBPs and the subsequent jet engines must still be scarring me subconsciously.

 

[mr_roboto]

My main concern is that with the much lower AS power consumption, and thus heat, I was kind of surprised they are still throttling, which bode poorly if Apple leans back into the whole ‘we can do even thinner now’ across the lineup.

But they've gone the opposite direction. Every time they've designed a new laptop chassis for Apple Silicon, it's been thicker than what it replaced. (the M2 Air did get thinner compared to the M1/Intel Air's thickest point, but the average thickness of the old wedge design was less than the M2 Air.)

The reason Apple Silicon Airs throttle is simply that Apple decided the best way to take advantage of AS in that product category was to remove the fan. The 13" MacBook Pro M1 and M2 have a fan, use the exact same chips as M1 and M2 Airs in a similar size laptop chassis, and they don't throttle at all.

The years of trying to drive multiple displays even with dGPU Intel MBPs and the subsequent jet engines must still be scarring me subconsciously.

The dGPU was actually a major factor in screaming fan syndrome there - can't blame it all on Intel. Due to the way Apple designed iGPU/dGPU graphics switching on those machines, there was no path for the Intel iGPU to drive external displays. Whenever you plugged one in, that forced the Mac to turn the dGPU on and switch over to it even when the graphics workload was light enough for the iGPU.

That was often a massive swing in total system power consumption, as those dGPUs weren't the most efficient things.

 

[theorist9]

But they've gone the opposite direction. Every time they've designed a new laptop chassis for Apple Silicon, it's been thicker than what it replaced. (the M2 Air did get thinner compared to the M1/Intel Air's thickest point, but the average thickness of the old wedge design was less than the M2 Air.)

The reason Apple Silicon Airs throttle is simply that Apple decided the best way to take advantage of AS in that product category was to remove the fan. The 13" MacBook Pro M1 and M2 have a fan, use the exact same chips as M1 and M2 Airs in a similar size laptop chassis, and they don't throttle at all.


The dGPU was actually a major factor in screaming fan syndrome there - can't blame it all on Intel. Due to the way Apple designed iGPU/dGPU graphics switching on those machines, there was no path for the Intel iGPU to drive external displays. Whenever you plugged one in, that forced the Mac to turn the dGPU on and switch over to it even when the graphics workload was light enough for the iGPU.

That was often a massive swing in total system power consumption, as those dGPUs weren't the most efficient things.

With that design you also got reduced reliability from thermal effects if you were using it as desktop replacement with external monitors, because then the dGPU was running continuously.

I had to twice bring my mid-2014 15" MBP in for service under AppleCare (once in Y2 and then again at the end of Y3) because the device started to thermal throttle to the point of effectively shutting down: I needed to keep an external fan blowing on its back to keep it from initating a 600%+ kernel process, which pretty much brought things to a halt. Intel Power Gadget said the CPU speed was reduced to 0.80 GHz. And it was definitely the dGPU, since I could also eliminate the throttling, without using the fan, by disconnecting the external monitors.

In both cases the progression was gradual—the time I could run it without the fan progressively decreased until I needed to run the fan continuously.

My best guess is the thermal paste kept breaking down.

After the 2nd fix I ran it for four years without issue (in the same configuration, with the externals), indicating Apple finally adjusted their MB's to handle continuously-running dGPUs.

Hopefully we won't see that same long-term issue with Airs used as desktop replacements when paired to a 5k or 6k monitor. I don't know what kind of sustained temps you'd see with an Air used in that manner.