Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

EDLIU

macrumors regular
Original poster
Oct 20, 2015
222
8
Are ARM Macs good?

What are the differences between an ARM Mac and an Intel Mac?
 
  • Haha
Reactions: Tagbert

high heaven

Suspended
Dec 7, 2017
522
232
It doesn't even exist so we know nothing about it. Until they announce it, it would be better to wait for it till 2021.
 

Fishrrman

macrumors Penryn
Feb 20, 2009
29,233
13,304
ARM-based Macs don't exist yet (outside of Apple's closed development rooms).

No one can answer this question.
 

Maximara

macrumors 68000
Jun 16, 2008
1,707
908
As I said elsewhere I am highly skeptical of ARM-Macs.

At least with the Intel there was evidence as far back as 1992 that efforts to get the MacOS to run on Intel with the Star Trek project (Computerworld made the obvious joke of "the OS that boldly goes where everyone else has been"). Yes, the project died a year later but there was at least official conformation that something was going on. To date no evidence of a Mac with an ARM chip running the MacOS has been reliably reported.

Yes there are benefits to going to ARM, for the laptops, but the cost is huge. The whole under the hood unix core will no longer compile all the ported to Mac code out there. Windows ARM has gone exactly nowhere and if an OS that dominates the PC world can't make ARM work as a desktop/laptop hardware platform then what chances does an OS that at best has perhaps 10% of the marketshare have?

Never mind, without an reasonable emulator, all the Intel Mac programs got nuked form orbit and Apple will have to support the Intel Mac for 2 to 3 years after their change over thanks to their referbs Macs.
 
  • Like
Reactions: Pearl Wisdom

chscag

macrumors 601
Feb 17, 2008
4,622
1,946
Fort Worth, Texas
Gloom and doom.... Apple has gone from Motorola to PPC to Intel and each time there were the naysayers who said it wouldn't work. I expect the engineers at Apple will once again come thru. Apple designed ARM chips are already running your iPhone and iPad. The T2 (which provides security) also ARM can be found in the iMac Pro, newer MacBook Pros and the latest Mac Pro.
 

Moonjumper

macrumors 68030
Jun 20, 2009
2,746
2,935
Lincoln, UK
As has been said, it is all speculation at this point, but here is my speculation:

I believe macOS has been running on Arm for years inside Apple. Describing their chips on iOS as “desktop class” is preparing us for when Arm macOS is announced. That was the very last time there was the possibility they had just started Arm macOS, but it was almost certainly long before then.

macOS and iOS are written on the same core. Xcode makes it easy to switch architecture. For anyone who has written code to Apple specifications, most, or even all, will work straight away. So a lot of ported software will appear more quickly than in the PPC to Intel switch.

Office to Photoshop, and beyond, have iOS apps. The developers of a lot of professional software have their code base working on Arm. It won’t be a shock in the same way the last switch was.

The Pro machines will likely swap last as that is almost certainly where the majority of Bootcamp and Parallels users are. Apple will have solid data on how many users of Windows on Mac hardware there are.

Apple may even bring out new lines initially to allow Arm options without removing Intel choices. There will certainly be some lower end machines in the first wave, such as the return of the MacBook. But there will be a high powered computer to show Arm isn’t a performance compromise. This machine might be available to developers ahead of launch for porting purposes.

The advantages will likely include lower cost, and avoiding the current performance stagnation.
 

Krevnik

macrumors 601
Sep 8, 2003
4,101
1,312
Yes there are benefits to going to ARM, for the laptops, but the cost is huge. The whole under the hood unix core will no longer compile all the ported to Mac code out there.

This doesn’t compute. The Raspberry Pi and similar SBCs are Linux on ARM, and are well supported. I use Swift compilers on my Pi today.

Because of inroads ARM servers are currently making, this sort of change over is likely going to be easier than it sounds. The main gotcha are libraries using assembler, as it always has been.

Windows ARM has gone exactly nowhere and if an OS that dominates the PC world can't make ARM work as a desktop/laptop hardware platform then what chances does an OS that at best has perhaps 10% of the marketshare have?

TBH, Microsoft didn’t deliver any compilers for ARM to third party devs until very recently. The original ARM Surface was DOA because of it only supporting .NET binaries from devs.

Microsoft in general can’t get devs to adopt anything outside Win32 with any reliability, and it’s at least half their own fault, half a victim of their own success.

Never mind, without an reasonable emulator, all the Intel Mac programs got nuked form orbit and Apple will have to support the Intel Mac for 2 to 3 years after their change over thanks to their referbs Macs.

Apple has switched architectures 2 times now, both times they used translation engines to let PPC run 68K and Intel run PPC. Microsoft already has a similar one for x86 on ARM (but 32-bit only sadly).

It is doable.

That said, I’m still on the fence on if Apple will do it.
 

Maximara

macrumors 68000
Jun 16, 2008
1,707
908
Apple has switched architectures 2 times now, both times they used translation engines to let PPC run 68K and Intel run PPC. Microsoft already has a similar one for x86 on ARM (but 32-bit only sadly).That said, I’m still on the fence on if Apple will do it.

The problem is that Apple itself didn't have a referb market back when they switched architectures that two previous times. This time Apple sales referb Macs that are as much as three years old and could be all the difference in the world you need.

This doesn’t compute. The Raspberry Pi and similar SBCs are Linux on ARM, and are well supported. I use Swift compilers on my Pi today.

How well does LibreOffice run on those machines? Or Inkscape. Or Handbreak. Or something like the Sims?

Because of inroads ARM servers are currently making, this sort of change over is likely going to be easier than it sounds. The main gotcha are libraries using assembler, as it always has been.

Gads, I didn't think anyone messed with assembly based language any more given how tied to the hardware they can be. With today's hardware and tend to cross platform build I have to ask why?!?

TBH, Microsoft didn’t deliver any compilers for ARM to third party devs until very recently. The original ARM Surface was DOA because of it only supporting .NET binaries from devs.

And we have gotten how many compilers for ARM on Mac? Seems to be the same problem.

Microsoft in general can’t get devs to adopt anything outside Win32 with any reliability, and it’s at least half their own fault, half a victim of their own success.

Yes this is an issue. Many people want to (or worse have to) hang on to their old programs or programming methods with a grip that makes Grim Death look like a limp noodle. :)


That said, I’m still on the fence on if Apple will do it.

They really need to have their act together to make this work. Never mind as I have pointed out before on the real low end Apple uses Intel video chips for their graphics.
 
Last edited:

Krevnik

macrumors 601
Sep 8, 2003
4,101
1,312
The problem is that Apple itself didn't have a referb market back when they switched architectures that two previous times. This time Apple sales referb Macs that are as much as three years old and could be all the difference in the world you need.

My first Mac was a refurb PowerMac 8600, bought direct from Apple. Refurbs are not a new thing for them. Supporting old machines isn’t new either. It took years for PPC to get dropped from new macOS versions (2009 when 2005 introduced the first Intel machines). 32 bit Intel finally got dropped this year. Fat binaries are still an option going forward.

How well does LibreOffice run on those machines? Or Inkscape. Or Handbreak. Or something like the Sims?

Can’t even compare these SBCs (which have to have a BOM of under 20$) with the iPad most of the time, let alone a speculative ARM Mac. An SoC meant to be passively cooled is not in the same class as a high powered CPU like the ones from Ampere (also ARM).

This question is a bit like asking why someone should use Intel by asking how well software runs on the Atom CPU. Not the right question/comparison to make.

The right question is: do we think Apple can scale up a version of the iPad’s CPU cores for something like the MacBook Air or Mini? And I think they already have For the Air, the Mini is maybe a coin flip IMO. It depends on how long Apple has been working on this, or if they have at all.

Gads, I didn't think anyone messed with assembly based language any more given how tied to the hardware they can be. With today's hardware and tend to cross platform build I have to ask why?!?

SIMD extensions are the most common. But some assembler functions in C do still exist, but they tend to be low level or encoder/decoder related. Most things should be fine.

Handbrake on the other hand...

And we have gotten how many compilers for ARM on Mac? Seems to be the same problem.

Technically, they already exist as cross-compilers. Darwin iOS is an ARM target after all, and the only real difference is getting the whole Mac SDK built and available, as well as self hosted compilers. And for self-hosted ARM compilers, clang and LLVM already build on ARM64 (and 32-bit ARM if you are a masochist). If Apple announced a shift at WWDC, you can bet the ARM tool chain would be available same day like it was with Intel. This isn’t a challenge.

The whole reason I brought up Swift on the Pi is that to build the Swift tool chain, you are building clang and LLVM as well. Swift compilers exist on 32-bit and 64-bit ARM today. ARM servers have driven a lot of that effort, BTW.

They really need to have their act together to make this work. Never mind as I have pointed out before on the real low end Apple uses Intel video chips for their graphics.

And Apple can use something else for GPUs if they want. Honestly, embedding something from AMD (something even Intel has done for a couple CPUs) would make a lot of sense here. The iPad GPU cores may be able to scale up, but it’d be something Apple would have to be working on, while an AMD integrated GPU could be effectively pulled off the shelf, especially since TSMC fabs for both AMD and Apple.

These aren’t major engineering hurdles. This is just the todo list of an architecture shift.
 

EDLIU

macrumors regular
Original poster
Oct 20, 2015
222
8
Another stupid question. Why Apple is going to do another "architecture shift"?
 
Last edited:

Krevnik

macrumors 601
Sep 8, 2003
4,101
1,312
A stupid question. Why Apple is going to do another "architecture shift"?

We don’t even know for sure if they will or not. We just have rumor and speculation. But why did Apple switch to PPC? Why did they switch to Intel?

The main benefit right now for Apple to switch to ARM is to take control of its destiny for CPUs. That and we have ARM CPUs that can be passively cooled, and yet still keep up with Intel‘s low end laptop offerings. The big question mark is if they can scale up to be feasible in the whole Mac product line or not. That’s where I’m skeptical of these rumors.

But there’s also the risks. They would open themselves up to the same risks they had towards the end of the life of PPC. Effectively painting them into a corner. Especially if they are the only ARM CPU designer producing desktop-class designs. And they’re going to get compared to Intel and AMD constantly again.

Personally, I wouldn’t put it past Apple to be looking at this, but I have a hard time giving it odds as high as 50/50. This is a super risky move unless they’ve got something absolutely insane up their sleeve.
 

nick9191

macrumors 68040
Feb 17, 2008
3,407
313
Britain
Another stupid question. Why Apple is going to do another "architecture shift"?

I don’t think the transition will occur like people expect. My gut feeling is that they won’t port macOS to arm, but rather continue the process of beefing up iPadOS to the point where it’s a successful laptop replacement for a segment of the market. See the iPad Pro that now supports mouse input.

So what we’ll see first, I think won’t technically be a Mac. It will be an iPad Pro in a laptop, possibly with a detachable touch screen display so that it can be still used as an iPad and a further beefed up version of iPad OS. “iBook” for a name anyone? ?

Then as time moves on they will add Arm chips in addition to Intel chips in Mac laptops running traditional macOS, which if done right could yield serious performance gains. I don’t think they’ll be in a position for a good few years to remove Intel chips entirely from their Pro Macs as Arm whilst fast can’t yet compete with Xeon.
 

throAU

macrumors G3
Feb 13, 2012
9,198
7,344
Perth, Western Australia
Another stupid question. Why Apple is going to do another "architecture shift"?


Because at the moment they do not make the processors in the Mac, they currently rely on intel.

Intel right now isn't doing so great (they've been stuck getting 5% performance per year, TOPS for the past 5 years, whilst Apple have been getting improvements of 5-10x that), much like Motorola was back when they changed from PowerPC.

Rather than switch to somebody else's processor (e.g., AMD) if apple build their own (which they already do for the iPhone, iPad, appletv, etc., then they are not waiting on someone else to build the things they want or include the features they want.

Last time they switched architecture, apple did not design their own processors. Now they do, so if they change, it makes sense to change to something they control and can extend/improve as they see fit.

intel don't build the parts Apple necessarily want, they build for the larger market including PCs, and Apple basically get whatever intel decides to make. If apple roll their own, they can customise it to be exactly what they want.
 
  • Like
Reactions: matrix07

thekev

macrumors 604
Aug 5, 2010
7,005
3,343
SIMD extensions are the most common. But some assembler functions in C do still exist, but they tend to be low level or encoder/decoder related. Most things should be fine.

Handbrake on the other hand...

Unless they're writing drivers or something, they are probably using intrinsics today rather than inline assembly for most things.

In both cases, they would still have to write new versions anytime there's significant divergence in instruction set architectures. On x86, SSE in particular is designed with different constraints in mind than any of the AVX variants, especially in their preferred methods of dealing with unaligned memory access. AVX really requires fast unaligned access if unaligned access is required. Otherwise it ends up creating too much register pressure if unrolled enough times to hide common instruction latencies on hardware targets that use it.

I don't see that as being a huge barrier though. Simd on x86 has been fragmented forever, and Neon definitely isn't bad.
 

Krevnik

macrumors 601
Sep 8, 2003
4,101
1,312
Unless they're writing drivers or something, they are probably using intrinsics today rather than inline assembly for most things.

In both cases, they would still have to write new versions anytime there's significant divergence in instruction set architectures. On x86, SSE in particular is designed with different constraints in mind than any of the AVX variants, especially in their preferred methods of dealing with unaligned memory access. AVX really requires fast unaligned access if unaligned access is required. Otherwise it ends up creating too much register pressure if unrolled enough times to hide common instruction latencies on hardware targets that use it.

I don't see that as being a huge barrier though. Simd on x86 has been fragmented forever, and Neon definitely isn't bad.

No disagreement there, I was trying to keep things a little simpler for the forum audience here. I even point out that it’s more a checklist of things to do than a real technical hurdle.

The real fallout is the lag time as projects that don’t already have coverage for ARM intrinsics get it added (if ever). 3rd party software on macOS has benefited from projects already optimizing for x64 SIMD. I’m not entirely sure we’d see such consistent availability on ARM for a while, based on how PPC SIMD wasn’t well supported. Especially with OSS projects that are dependent on libraries like Handbrake. x265 in particular only seems to have x64 implementations at the moment.
 

thekev

macrumors 604
Aug 5, 2010
7,005
3,343
No disagreement there, I was trying to keep things a little simpler for the forum audience here. I even point out that it’s more a checklist of things to do than a real technical hurdle.

Yeah I'm bad about that, although this forum gets a lot of enthusiasts, who may be familiar with it.

The real fallout is the lag time as projects that don’t already have coverage for ARM intrinsics get it added (if ever). 3rd party software on macOS has benefited from projects already optimizing for x64 SIMD. I’m not entirely sure we’d see such consistent availability on ARM for a while, based on how PPC SIMD wasn’t well supported. Especially with OSS projects that are dependent on libraries like Handbrake. x265 in particular only seems to have x64 implementations at the moment.

I am starting to see your point. Man these x265 guys really like their assembly. Their docs say the project was launched in 2013. Compilers around that time could really butcher even carefully written intrinsics code compared to today, so getting something reasonable may not be as painful as it once was. Some of those routines are simple enough that I would probably start by trying #pragma simd before anything else with an up to date clang, and I would expect a future ARM mac to require an extremely up to date toolchain.
 

Pacific1972

macrumors regular
May 2, 2020
128
104
Germany
What a stunning question at the top - also I can ask of your microcosmos ;)

...explained myself this and hope I'm not too boring, my english is okay and
hope that people don't recognise too fast that I'm only half of a nerd !

There was a time when Atari, Commodore, Amstrad, Apple and IBM make a run for
customers - when Commodore has GFX & Games, Atari has Syntesizer Music and
MIDI, IBM build Business Computers and Apple build computers for money honks
(the opposite of nerds) or Dreamers with their own graphic studio - which are printing
T-Shirts and make some other life important things - but only with MacIntosh... :D

In the United Kingdom & Commonwhealth there was a brand named Acorn which
build Computers with RISC CPU, because "ARM" means ACORN RISC MACHINES.

These Acorn Archimedes with a RISC CPU puts all the power any other brand wants
to have - in personal portfolio & price - in one piece of silicium in the 1990's...

A DX486 as second CPU Card are running DOS and Windows 3.1 in a native window
on the ARM based RISC PC. Between 1990 and 2000 I have had a few Commodore,
Amstrad and PC Computers.

Nearly unbelieveable in the past was the Happy Computer information (?) about
Acorn in the past- this machine was a "Flying Unicorn" for me !

riscpc.jpeg

Acorn RISC PC 20 years ago - ask about Apple Computer Design at the Millenium ?

Long time ago ACORN had outfitted all UK national school and university with these
computers - RISC OS, ARM Assembler and BBC Basic - and I think a university degree
in information technology was worth much more 25 years ago than today - the students
of the past often had MUCH MORE experience in programming than today because of
low GFX and CPU speed - ask the professors !

Today it's not anymore so important how fast a chip CPU / GPU is standalone,
the environment is also same important - to anticipate what Apple plans ?

About the predicted price of a new ARM IMac I expect the power of perhaps
16x Raspberry PI 4 Cluster together with 16-32GB RAM, SSD and GPU.

If people need Intel there comes an Intel SOC like Raspberry for Windows Core
compatibility as PlugIN second CPU - nice to have - also I like the jovial cooling
devices inside my IMac and exchangeable IMac GFX Cards (also expensive at the
time "ebay collector prices" as same trashy one-way technology if your are
looking for an original Apple card - for the same price I can buy sometimes a
complete Hackintosh...

Can you use products of any other brand like an IPad Pro ? Think about human
interference & interaction with future technology - openminded ?

:apple:;):apple:
 

Dean Yu

macrumors regular
Mar 12, 2016
162
134
Toronto, Canada
Posted this before in another thread but I might just do it again here.

With what we know about the first MacBook ARM chip (based on A14 architecture, 8 performance cores + 4 efficiency cores) this mythical MacBook can have the CPU performance of a 7K+ 12 core Mac Pro.

Without any optimization a Surface Pro X with Qualcomm SQ1 runs x86 version GeekBench4 at roughly 60% speed of ARM GB4 (2200 vs. 3500 single core, and 6750 vs. 11500 multi core). After all it’s a heavily multithreaded and SIMD dependent benchmark running on Win32 emulation layer…

And the single core performance of this alleged “phone chip” times 60%, is pretty much the base line 8 core Mac Pro…
(That is, without considering sustained load)

Without porting AVX or SSE extension codepaths from x64 one can just *brute force* everything, aka literally emulating a x64 chip much faster than a real i5 ;)
[automerge]1588555056[/automerge]
What a stunning question at the top - also I can ask of your microcosmos ;)

...explained myself this and hope I'm not too boring, my english is okay and
hope that people don't recognise too fast that I'm only half of a nerd !

There was a time when Atari, Commodore, Amstrad, Apple and IBM make a run for
customers - when Commodore has GFX & Games, Atari has Syntesizer Music and
MIDI, IBM build Business Computers and Apple build computers for money honks
(the opposite of nerds) or Dreamers with their own graphic studio - which are printing
T-Shirts and make some other life important things - but only with MacIntosh... :D

In the United Kingdom & Commonwhealth there was a brand named Acorn which
build Computers with RISC CPU, because "ARM" means ACORN RISC MACHINES.

These Acorn Archimedes with a RISC CPU puts all the power any other brand wants
to have - in personal portfolio & price - in one piece of silicium in the 1990's...

A DX486 as second CPU Card are running DOS and Windows 3.1 in a native window
on the ARM based RISC PC. Between 1990 and 2000 I have had a few Commodore,
Amstrad and PC Computers.

Nearly unbelieveable in the past was the Happy Computer information (?) about
Acorn in the past- this machine was a "Flying Unicorn" for me !

View attachment 911897
Acorn RISC PC 20 years ago - ask about Apple Computer Design at the Millenium ?

Long time ago ACORN had outfitted all UK national school and university with these
computers - RISC OS, ARM Assembler and BBC Basic - and I think a university degree
in information technology was worth much more 25 years ago than today - the students
of the past often had MUCH MORE experience in programming than today because of
low GFX and CPU speed - ask the professors !

Today it's not anymore so important how fast a chip CPU / GPU is standalone,
the environment is also same important - to anticipate what Apple plans ?

About the predicted price of a new ARM IMac I expect the power of perhaps
16x Raspberry PI 4 Cluster together with 16-32GB RAM, SSD and GPU.

If people need Intel there comes an Intel SOC like Raspberry for Windows Core
compatibility as PlugIN second CPU - nice to have - also I like the jovial cooling
devices inside my IMac and exchangeable IMac GFX Cards (also expensive at the
time "ebay collector prices" as same trashy one-way technology if your are
looking for an original Apple card - for the same price I can buy sometimes a
complete Hackintosh...

Can you use products of any other brand like an IPad Pro ? Think about human
interference & interaction with future technology - openminded ?

:apple:;):apple:

In case you forgot a thing or two about Newton, Apple deliberately abandoned the use of ACORN in favor of Arm after some unsuccessful trials.
 

Attachments

  • 26D5739F-3E56-49F5-A3F2-0E43C4FBEAC1.jpeg
    26D5739F-3E56-49F5-A3F2-0E43C4FBEAC1.jpeg
    36.8 KB · Views: 163

nukenight

macrumors member
Feb 16, 2012
31
19
This is all going to come down to will MS Office apps run on this new setup? Mac was a toy computer and not taken seriously until MS decided to make nice with Apple. Keep this is mind. We have endured chip changes twice... WE don't need another CF in this regard.
 

thekev

macrumors 604
Aug 5, 2010
7,005
3,343
Without porting AVX or SSE extension codepaths from x64 one can just *brute force* everything, aka literally emulating a x64 chip much faster than a real i5 ;)

As amusing as that is (also even with the wink, I can't tell how much is sarcasm), any kind of interpreter is going to be much slower than the real thing. Ignoring simd extensions, you are still effectively implementing an interpreter for the corresponding assembly. Even if this interpreter is well optimized, it's still going to be a big speed hit. Ignoring simd extensions just means that you are presumably mapping a certain amount of the language to register as invalid opcodes.
 
  • Like
Reactions: ssgbryan

throAU

macrumors G3
Feb 13, 2012
9,198
7,344
Perth, Western Australia
As amusing as that is (also even with the wink, I can't tell how much is sarcasm), any kind of interpreter is going to be much slower than the real thing. Ignoring simd extensions, you are still effectively implementing an interpreter for the corresponding assembly. Even if this interpreter is well optimized, it's still going to be a big speed hit. Ignoring simd extensions just means that you are presumably mapping a certain amount of the language to register as invalid opcodes.

Yes and no.

If for example the application uses Apple provided macOS/iOS frameworks (like uh... virtually every macOS and iOS app) it can call native versions of the frameworks included in the OS.

So... sure... if you are writing AVX code directly you might see an issue. But if you are using say, Metal or OpenCL, or any one of the other provided macOS frameworks for doing the heavy lifting, as recommended, then your application simply links to the provided framework and uses whatever the best hardware the end device has to do the job, the best way it can.

This is how Apple managed the PPC -> X86 switch and ended up with equivalent speed machines on day 1 that only got faster from there.

Also how they did the 68k to PPC switch.

If you're writing assembly directly on macOS you're normally "doing it wrong", and for the vast majority of apps that use frameworks, emulation speed is mostly irrelevant because the only code being emulated is generally the glue code for message passing between the apple frameworks doing most of the heavy lifting - natively.

So yes, emulation is slow. But that's not how the vast majority of the applications will be running. It will be emulated glue code calling native frameworks. The glue code that links all the heavy lifting functions together in a typical app may be say 10% of the run-time in a typical app (the remaining 90% being performed by a framework/library for math, graphics, etc.).

Even if you blow that 10% out by 100%, you're looking at a 9-10% increase in total run-time; and presumably that will be off-set by the more powerful CPU running the other 90% of the code run-time that uses Apple's native frameworks (i.e., if the new processor runs even 10% faster than the previous x86 CPU, then that will off-set the 100% increase in runtime of the glue-code).

Those numbers above aren't exact, but the same basic theory will apply, for apps that make use of Apple native frameworks like Metal, OpenCL, OpenGL, etc. for their heavy CPU work.

So yeah - emulation is slow. But it mostly just doesn't matter, because most of the code won't be emulated. This is an advantage of the way Apple does object linking in macOS and iOS.

Yes there will be exceptions; the vendor may have their own custom tuned framework written in low level code. They'll need to port that or have its performance suck in emulation. But those will be the exception rather than the rule - and if they are doing that, they're well behind the curve.
 
Last edited:
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.