
Apple to debut multiple ARM MacBook, desktop models in 2021 - t4h4
https://appleinsider.com/articles/20/03/26/apple-to-debut-multiple-arm-powered-mac-desktop-and-laptop-models-in-2021
======
_ph_
I am torn, whenever I hear the rumors about the ARM Macs. On the one side, I
am terribly excited from a technology perspective. I grew up with
homecomputers in the 80ies, and in the 90ies, all Unix-workstations had
several different, non-x86 architectures. So any disruption of the
x86-monoculture is interesting. Also, looking at the performance of the iPhone
and iPad, I think Apple has the potential to create some great hardware. It
would also give them more flexibility to roll out new features.

On the other side, such a transition always is painfull. A lot of software
needs to be rebuilt, and even more legacy software gets killed, as it is not
ported to the new platform. Though Catalina already did a lot of that, and
that might not be a coincidence, if you think about it. Catalina might be
intentionally restrictive to ease the transition to another architecture.

Also, a lot of Mac users are running VMs on their machines. Running Windows
and Linux VMs on your Mac was one big benefit of the switch to Intel. I myself
use a Linux VM for my professional work on a MB Pro. And that VM needs to be
able to run x86 software. So it remains to be seen, how Apple deals with the
MB Pro (and of course the Mac Pro).

~~~
ianai
They could make an x86 daughterboard for the Mac Pro. Plenty of space for that
and it’s been done decades ago. Or a third party could.

I wonder whether they’ve got any special killer apps in mind for the desktop
and MacBook ARM machines. They could theoretically customize them greatly
since they’re designing the architecture. Also wonder whether they view
keeping the unix developer pipeline.

~~~
philwelch
iOS development and, potentially, better support for Catalyst are the obvious
pluses I haven’t seen mentioned yet.

~~~
ianai
Or graphics algorithms tailored to many cpu cores instead of just gpus. Or
have the Mac platform interoperate with their mobiles better, again.

~~~
philwelch
Graphics algorithms for what? Mac is still such a small market share that
third party developers won’t take advantage of any weird architectural
advantages. Sony tried and failed to pull this off with the PS3’s Cell
processor, which was ironically PowerPC-based.

~~~
ianai
FCP, Adobe, etc. Apple has enough market power, cash, and know how to pull
some combos and killer features off.

------
Traster
To be honest, I am super unexcited by this. What I want to see from Apple is a
move back to high software quality, high hardware quality and real vision for
their products. At the moment their convergence between iPad and Macbook has
essentially been to add sub-par versions of macbook features to the iPad and
to make the macbook a second class citizen in terms of quality.

My big worry is that actually this is just acting as cover for deep underlying
issues in a lack of real vision for how the iPad can become a real replacement
for laptops and no vision at all for the desktop line. How crazy is it that
Apple is pumping out products that re-implement Microsoft features from 5
years ago (after spending 5 years mocking Microsoft).

~~~
seanmcdirmid
I owned a surface and I own an iPad Pro now. They aren’t even comparable in
usability, Apple is great at refining features and making them work even if
Microsoft is better at getting them out earlier. It’s like comparing the
iPhone to WinCE.

------
rubyn00bie
Yep, the real give away was the A12Z. It isn't shit all faster than the A12X
with the exception of the added GPU core.

The A12X was so fast when it came out, reviewers were like "holy shit, this is
nearly as fast or faster as comparable x86 laptop," and that was what... two
years ago?

Apple's ARM processors are likely _so fucking fast_ that they'd absolutely be
showing their hand if they put one in a tablet right now. Reviewers would
probably be like "uhh this is faster than a 13" macbook pro and it's a fucking
tablet?!" Not to mention, that'd be the nail in the coffin for a good (for
Apple) relationship with Intel until they're totally ready to transition.

My guess is Apple is probably just not "quite" there yet for it's highest-end
products or we'd see them this year. It's pretty lucky for them their custom
silicon to-date has been so far ahead of everyone else or (appearing to be)
sitting on their asses for a year or so might hurt.

TSMC is already capable of taking a shit on Intel (Ryzen 3000) and Apple is
obviously capable of making very fast custom CPUs. It's a pretty dangerous
combo if you're Intel right now and already getting hammered by AMD.

For me, the real question, and pipe dream, will Apple partner with AMD during
the transition and perhaps make some some hybrid AMD x86/Apple ARM machines
since they're both being built by TSMC?

~~~
_ph_
_For me, the real question, and pipe dream, will Apple partner with AMD during
the transition and perhaps make some some hybrid AMD x86 /Apple ARM machines
since they're both being built by TSMC? _

There is an interesting thought. Apple could embed one AMD-chiplet with up to
8 cores into their designs, where Apple provides the ARM-CPUs as well as the
io-hardware the chiplets require. This would retain the ability to run
x86-code, while the system would use the ARM-hardware for most task.

~~~
taylodl
Bingo! This is _exactly_ what I see happening!

~~~
arvinsim
Would that significantly increase cost?

~~~
taylodl
Actually it would give them something with which to differentiate their _Pro_
lines: they would have the x86 processor along with the ARMs.

------
thought_alarm
Always a year away.

I remain deeply sceptical that Apple will move the Mac to ARM, and given their
bungling of the MacBook lineup over the last 5 years I have doubts they
understand what their users need from a laptop. I don't think they could pull
it off without a great deal of pain for their users and developers. I don't
think their OS engineers need the burden.

~~~
ttul
They’ll do it on a select model or two. By passing on some of the cost savings
to purchasers, they will drag the market along with them as they gradually
replace Intel. I would guess that they target the MacBook Air first, because
there are likely large power-performance benefits in that form factor. They
will build multiple processor targeting into the default build process in
Xcode and will invest a great deal of effort and time into ensuring that app
developers are well supported with the targeting of ARM.

They did this before with the move to Intel from PPC. And back then, Apple was
a great deal smaller.

~~~
ghaff
Or the (currently discontinued) MacBook. The evidence (and logic) suggests
that Apple is on a path to reconverge their tablet and at least a portion of
their laptop line. Which would be interesting to me if the merged device
didn't have too many compromises given that I typically travel with an iPad
and some sort of laptop (whether MacBook Pro or Chromebook).

------
zootam
This is nothing new, just the latest rehashing of the same rumor that's been
recirculating for months.

~~~
davidgerard
yeah, I was looking for something more than a single analyst's note here.

~~~
arikr
Kuo has an excellent track record on Apple predictions from what I understand.

~~~
dzhiurgis
Who is him anyway? I’ve never been able to trace that.

------
dhhwrongagain
Get ready to not have root access on your laptop. The writing is on the wall:

    
    
      * signed software restrictions 
      * no kernel extensions
      * SIP
    

Dropping x86 compatibility will be the last nail in the coffin. Buy the x86
platform if you value your freedom, buy arm if you want a larger form factor
smartphone

~~~
rgovostes
There's no evidence for this. They could remove root access now on x86 if they
wanted to. They didn't have to spend engineering hours making it possible to
disable SIP when they turned it on. Most software signature restrictions that
have been added to macOS to date are easily disabled, and besides that have
nothing to do with x86 vs ARM.

------
izacus
I wonder if they'll use that as an excuse for complete lockdown of macOS and
only allow AppStore reviewed software.

~~~
wool_gather
They can't do this unless they are okay with never selling machines again to
_anyone_ who needs to write code. There's no feasible way for all programming
tools to be distributed through MAS. IPython isn't going to suddenly go
through the marathon of crap you need to get into the store.

If absolutely nothing else, native developers: you can't have more than one
version of a MAS app installed. Nearly every iOS developer I know has at least
two versions of Xcode at any given time.

~~~
dhhwrongagain
That’s not true. Many people write code on Mac despite kernel extensions being
disabled and SIP. What will be considered root will be a superficial emulation
convincing enough to fool most Unix software

------
strategarius
I'm curious what Parallels going to do. Running Windows and Linux applications
with almost native integration into OSX ecosystem worth a lot, especially with
all benefits of hardware virtualization. In theory PC could be virtualized on
ARM, however software virtualization only. Going to watch the process. In
general, Windows and Linux support ARM as well, not sure if hardware
virtualization for ARM exist though

~~~
pmontra
Maybe backend developers for Intel Linux servers will fire up a VM on
AWS/Azure/Google and work there.

There will be some cross platform compatibility issues. Interpreted languages
hide the CPU (think Python, Ruby, Node) but their extensions in C could need
some extra work that not all of them require now.

On the other side there will be the rise of the ARM servers. Apple is
notoriously not interested in running server farms for their customers but I
expect that the big cloud providers will start offering ARM servers.

It could be the x86 developers to have to fire up an ARM VM on the cloud to be
able to work in ARM Macs heavy teams.

~~~
scarface74
Packages with native dependencies already require a recompile to run between
Windows and Linux. Right now, I write Python scripts on a Windows laptop, push
the changes and the build server (well actually a Linux Docker container using
AWS CodeBuild) builds and deploys the package to Linux servers.

Apple already has an x86 build chain that cross compiled to ARM.

------
fit2rule
I'd be completely fine with a switch to ARM, as long as it was handled in the
same way that the switch to x86 was done - with a period of fat binaries
targeting both architectures, and then a gradual phase-out of the older
architecture (x86).

I'm pretty sure Apple have the ability to put 32-core ARM systems into the
MacBook, and push the power/processing ratio into the stratosphere. The only
reason I'm not using ARM right now, personally, is because such a thing
doesn't really exist .. but I look at my old Touchbook up on the shelf and
wonder what could have been...

------
Causality1
Other than Linux distros, almost every home OS on ARM is a locked-down anti-
consumer mess. Android, Windows RT, iOS, Windows X, Chrome OS. I'm hoping
MacOS doesn't follow them down that road of locked bootloaders and anti-root
restrictions.

------
raverbashing
Still to be confirmed, I don't usually take "analyst predictions" too
seriously but I found this interesting:

"Apple will no longer be held to the whims of Intel"

Apple switched to Intel because IBM couldn't ship a good enough G5 for
notebooks and for scale issues. Given that Intel is not on track with 7nm and
rumours of their CEO being seen in Taiwan the other day it seems history is
repeating itself.

~~~
unlinked_dll
I mean if it's just about performance, why switch architectures instead of
using AMD chips?

~~~
oefrha
Alan Kay: “People who are really serious about software should make their own
hardware.”

Apple: People who are really serious about hardware make their own processors.

~~~
birdyrooster
Eventually you become Ford and build a River Rouge Plant where you do all of
your own metallurgy and parts manufacturing. Completely vertical.

------
jshaqaw
The question is as users should we care? If this is cheaper for Apple will
they actually lower product prices or just enhance their own margins. Will
this result in any superior performance on a cost-adjusted basis?

~~~
mikhailt
Of course, we should care. We are talking about losing the standard x86
platform support (which allows for Windows/Linux support if not total OOB
support) to a custom Apple platform that may be more locked down to the point
that Linux may not even care to add any support for it (T2-Macs have been
difficult to add support in Linux). This drops the value a lot if you're not
an exclusive macOS user.

1\. We don't know what impact this will have for Bootcamp and Windows, since
Windows 10 on ARM right now is customized for specific ARM CPUs like
Snapdragon.

2\. Same for virtualization, we don't know the performance hit it is going to
have. A lot of people still need to use Windows for specific software that is
not available on Windows or macOS where 32-bit support can be retained with
older macOS releases.

3\. Going the other direction, ARM means we could also see easier porting of
iOS apps to macOS via Catalyst with more consistent APIs. But that could also
mean less focus on macOS overall and everyone switching to iOS to port to
macOS rather than working on two separate versions. This has both pros and
cons and we won't know the full extent until a few years later.

~~~
scarface74
Porting iOS to Macs don’t require ARM. Almost every iOS app started life
running on x86. The iOS simulator runs iOS software compiled for x86 linked to
x86 versions of the iOS framework.

~~~
mikhailt
I didn't say it does, I'm just saying that it'll be easier. Instead of working
on both x86/ARM frameworks, they'll just stop supporting x86 (freeze) and only
update on the ARM framework from now on.

They did the same thing with PowerPC and x86-32. No reason to expect them to
support x86-64 in 5-10 years if they switch all Macs to ARM.

------
DeathArrow
Apple would love more lock in and transforming Macs into giant iPhones with
app store only apps.

However, breaking compatibility with Windows and Linux would be a terrible
idea. People would flee to other platforms leaving Mac for those who are
already locked in, like iOS developers.

People care most about running their software to do their work, than what os
they use.

------
outside1234
Is it really going to be a MacBook - or a laptop form for the iPad Pro?

------
wyre
What does this mean for software companies whose consumer base is largely on
OSX? Will Adobe, Sony, Avid, etc have to port their library of software over
to Apple's new ARM architecture?

Will this allow for greater freedom with ARM devices not running new OSX?

It seems like Apple lately has very much internalized 'if you build it, they
will come' even though it seems like it is heavily alienating their
professional user base.

~~~
scarface74
You act as if this is the first time that Apple has done a transition or the
first time that the aforementioned companies have made the transition.

Each of them have made the transition from 68K -> PPC -> OS X -> x86.

~~~
wyre
I only know about the transition to x86 and from what I remember the benefit
was the same architecture as Windows. Since them OSX has gained a lot of
market share. Moving to ARM is definitely a step backwards in that regard. I
don't know anything about the previous transitions.

I don't think transitioning to ARM is a bad choice given the benefits, but a
lot of serious (and casual) users are going to be very unhappy their programs
aren't going to work after dropping $1k+ on a new computer.

~~~
scarface74
The Mac was already on an upward trajectory before the x86 transition. OS X
hasn’t really gained that much marketshare. Besides the “beleaguered years”,
Macs have historically trended at around 10% market share. They actually had
more marketshare in the early 90s before Windows 95.

Apple has done this three times if you include the Apple //e transition. Each
time they brought customer’s along.

The first transition from 68K to PPC, almost all of their revenue came from
Macs. The second time about half (the other half was iPods). Now it’s less
than 10%. It’s much less risky this time.

------
nodesocket
Is the switch to ARM going to be for cost savings, or are the chips actually
faster than current Intel?

~~~
phoobahr
[https://news.ycombinator.com/item?id=21033371](https://news.ycombinator.com/item?id=21033371)

~~~
sudosysgen
That's Geekbench. The differences in Geekbench for ARM devices and Geekbench
for x86 are laughable. Why not compare them in a real life workload like a
render on Blender or a kernel compile?

~~~
mikhailt
People have (Jonathan Morrison for an example) , the 4k exports from iMovie or
other video/image editor has been proven to be vastly faster on iPad Pro than
the fastest Macbook Pro.

Intel CPUs are not customized by Apple for their own APIs, they're for general
purpose use. yes, they have ISA extensions that Apple could use like QuickSync
but it's not enough for Apple.

Apple customize their A series with the same APIs they use, such as Metal,
CoreFoundation, Javascript Core (they have hardware-based JS acceleration
support), etc.

It's why they added T2 chips to their Macs to help accelerate a lot of tasks
like disk encryption, more locked down security with TouchID and so on.

~~~
Slartie
> the 4k exports from iMovie or other video/image editor has been proven to be
> vastly faster on iPad Pro than the fastest Macbook Pro.

I'd only be impressed if both used the exact same high-quality software
encoder. Most likely the iPad uses the fast but less quality dedicated
hardware encoder of the A-Series SoC and the MacBook uses a high quality but
slow software-only one, which is what you typically use in any non-real-time
encoding scenario due to way better bitrate-to-quality ratios.

> Javascript Core (they have hardware-based JS acceleration support)

Do you have a credible source for this? AFAIK JS VMs have gotten to the same
place that Java VMs (for which some people also envisioned dedicated silicon a
long time ago, but it was a dud) reached: so frickin fast on standard x86 ISA
that putting any special instructions for them into the ISA isn't worth it,
because it's more important to stay flexible to be able to adapt future
extensions of ECMAScript.

> It's why they added T2 chips to their Macs to help accelerate a lot of tasks
> like disk encryption, more locked down security with TouchID

That has more to do with having a secure element under Apple's control in the
T2 chip and nothing with performance. Any modern x86 CPU can do accelerated
AES just as fast as any ARM with hardware crypto support.

~~~
mikhailt
That is true, I don't have any evidence to say that x86 isn't faster or equal
against Apple's ARM CPUs or vis versa. They're hard to come by since they're
both completely different arch.

For JS:
[https://twitter.com/codinghorror/status/1049082262854094848](https://twitter.com/codinghorror/status/1049082262854094848)

It looks like it's not exclusive to Apple's CPU, it's the specific instruction
features in ARM 8.3 ISA that makes JS faster.

Added here:
[https://bugs.webkit.org/show_bug.cgi?id=184023](https://bugs.webkit.org/show_bug.cgi?id=184023)

> Any modern x86 CPU can do accelerated AES just as fast as any ARM with
> hardware crypto support.

Right but back then, Intel mobile chips weren't that fast. I had MBP with
Filevault that took a massive hit and I had to turn it off to get back disk
performance. I can't prove that T2 is the reason the encryption doesn't take
any hit on T2 Macs, all I can see from my trial of rMBP 16, there was zero
performance hit with it on or off.

~~~
Slartie
Thanks for the JS link, I didn't know about that. Though I would hardly call
that "Javascript acceleration in hardware". They added a slightly weird float-
to-int conversion command that handles overflows a bit different than the
normal command, and for lack of better names (and probably because no one else
is expected to require that quirky command) they put a "Javascript" into its
name.

The perf hit with Filevault became practically zero when Intel added the AES
encryption hardware into its chips, which was quite a while ago (and
definitely long before the T2 was a thing). I don't remember exactly when that
was, but I remember noticing a considerable difference, because I've used FDE
since it became available in Filevault. It wasn't even on Macs only, my
Windows machines also showed the same improvements using (IIRC) TrueCrypt back
in the days.

The dedicated AES hardware extensions in ARM and x86 cores are probably the
same logic anyway, so it shouldn't matter too much who decrypts the data.
Maybe it's a tiny bit faster with the T2 though, because then the CPU doesn't
necessarily have to pipe all the data through it's buses for decryption then.
But that is more or less a feature of having a dedicated separate chip for it,
and is thus not tied to the question of whether that chip uses ARM or x86 or
any other ISA.

~~~
sudosysgen
>The dedicated AES hardware extensions in ARM and x86 cores are probably the
same logic anyway, so it shouldn't matter too much who decrypts the data.
Maybe it's a tiny bit faster with the T2 though, because then the CPU doesn't
necessarily have to pipe all the data through it's buses for decryption then.
But that is more or less a feature of having a dedicated separate chip for it,
and is thus not tied to the question of whether that chip uses ARM or x86 or
any other ISA.

I don't really see how that would help, CPU i/o has to handle the exact same
amount of incoming data encryption or not. Maybe a bit less RAM impact though.

~~~
Slartie
My thought was this: If the CPU decrypts, it touches every byte being read to
RAM, and it touches the data again later when it does actual work on it. If it
doesn't decrypt, but a chip next to the NAND does the job, the CPU can DMA-
transfer the data directly from that chip to RAM. The first time the CPU
touches the data is when it actually does some real work on it.

~~~
sudosysgen
True, but my thought was that since AES decryption is mostly limited by RAM
bandwidth anyways, the transfer from the SSD to the CPU, then from the CPU to
the T2 chip, then from the T2 chip to the CPU won't be much faster than
transferring from the SSD into the RAM, then decryption, then it being read
back into the RAM.

~~~
Slartie
AFAIK the T2 is also the SSD controller in Apple's architecture, meaning it
speaks directly to the NAND. So it should not be necessary for data to first
go to the CPU, then to the T2 for decryption - the T2 can transparently
decrypt and encrypt while doing the job of offering block-device-level access
to the flash chips.

------
GrumpiNerd
Until they offer pro-level repair service they shouldn't be considered a "pro"
machine.

That means next-day onsite repairs. Not 3-5 days at a distant location,
leaving the user without their computer.

~~~
jlei523
You're thinking enterprise.

------
specialist
Shouldn't the first models to use ARM be desktop? Allow the early adopters to
kick the tires. So that devs can make sure their wares work on ARM before the
mass market models switch?

------
Waterluvian
The only reason I could come to care about architecture, as a consumer, is if
it provides a freakishly long battery life.

~~~
PopePompus
Does anyone have a rough figure for what fraction of the power load on a
macbook is going to the CPU? In other words, what's the limit in battery life
for a laptop whose CPU consumes no power at all, but still has to power the
display, refresh RAM, etc?

------
shmerl
Do Apple even care about their PC business? They basically let it rot.

------
Nursie
Still hoping for a 13/14 inch intel macbook refresh with the revamped keyboard
before too long.

Or I was, now that I work from home all the time my need for a laptop is much
reduced.

