Apple's move to ARM-based Macs creates uncertainty | Hacker News Reader

Apple's move to ARM-based Macs creates uncertainty

axios.com

79 pointsmsh126 comments

This is a super link bait title for a very short, speculative article.

Who knows if Apple will switch to ARM for their laptops. Even Apple may not know yet. We can be sure they are making some, just as they had various x86 efforts under way for many years during the PPC era.

This article only cites Intel sources, Of course this is something Intel should be concerned about, and causing some uproar in the press is a good way to lobby a large customer.

As much as Apple has neglected pros moving to ARM would definitely put video editors using Final Cut in the lurch. Its only really their macbook/macbook air lineups where a move to ARM/RISC looks truly appealing. I don't really think Apple wants to completely abandon creative Pros.

Yet if you aren't going to move the ENTIRE lineup off of Intel CPUs you're really limiting any potential benefit.

How are you arriving at this conclusion? It’s possible to transition from x86 to ARM without any loss of performance in the scenario you’ve described.

First of all the ARM chips Apple ships are designed for iOS workloads (check out the dominance of graphics in area and internal bandwidth on the iPad Pro chips -- it calls to mind the Alto's explicit tradeoff of bus bandwidth and screen refresh). Apple's ARM parts have been smokers for the past few generations but they aren't designed for the sustained performance and instruction mix targeted by Intel.

But that doesn't have to be true. MacOS CPUs need not be the same as the ones in iOS devices (after all they aren't today either).

Apple could very well design ARM instruction set chips with special pipelined or SIMD instructions that support, say, the kind of transforms Final Cut needs. They could make sure Photoshop was a barn burner on their machines if they thought that mattered. Etc.

The real question is the rest of the silicon (peripheral controllers like TB etc which they also get from their Intel deal).

As for the tired trope of "As much as Apple has neglected pros" -- I'm tired of hearing that. Yes of course their mix isn't perfect for everyone but holy cow, my MacBook Pro has 4 40GPS TB ports! Hell, I get a lot of work done on their smaller devices, and the ever increasing portability is a huge plus. I'm a pro, not prosumer, and it works for me.

I know my needs aren't the same as everybody else's, but I would bet that Apple knows the usage profile of everyone willing to share analytics, including how often people plug what sort of device into their machines. And I'm sure that informs their designs.

Every design will fail to be a perfect match for some set of pros, and of course they should complain. Maybe it's just that they are designing machines for me? (in which case: fix the damned touch bar).

You are basically talking about the A76 core[1] and modified derivatives and its successors (e.g. neoverse[2]).

[1] https://en.wikipedia.org/wiki/ARM_Cortex-A76

[2] https://en.wikichip.org/wiki/arm_holdings/microarchitectures...

The N1 is actually expected to be on par or faster than a Zen core in single threaded applications. Overall it would be a match for both Zen and Skylake-SP. Add to this Apple's specific brand of control over their software stack and you've got some exceptional potential to deliver high performance in a low power envelope.

And all this while giving Apple full control over every aspect of their product (whether it leads to good or bad outcomes). Which could mean actual yearly refreshes instead of forgetting about a product for years because Intel had nothing in the pipeline.

I mean if you're going to pay a hefty price premium you probably want something only Apple can give you. Not just a more expensive version of the same thing shipped by every other OEM out there.

Moore's law is dead. Switching architectures to something that is more customizable to your current process is one of the only ways to squeeze more performance out of a given chip. It's why companies are increasingly building their own ASICs. If Moore's law was alive, they wouldn't need to, they'd just wait for the next general purpose chip to come out.

This isn't just a matter of Moore's law. The lack of competition over the past decade also played a major role. Intel didn't feel pressed to deliver anything and instead decided to milk the market.

It doesn't even matter if tomorrow we find a way to bring back Moore's law (performance increase, not necessarily transistor density). Apple probably doesn't want to be back here 10 years from now if competition is dwindling.

And again, if they want to charge a lot more than the competition they have to justify it. This is the justification. Give me a super optimized CPU for which major software companies optimize their software and you've got my attention. I imagine Adobe would make sure their SW gets tha last drop of performance on Apple's machines. May not be the case with the competition's run of the mill ARM core.

It all comes back to Moores law. Today, there is more competition between chip fabs than ever. ARM is beating Intel in a number of markets. They are able to do so, because Intel is slowing down. Intel is slowing down because of Moore's law.

The idea that a company would optimize a chip to their specific purpose is also a consequence of Moore's law. If performance did exponentially increase, there would be no point in optimizing for a task, because by the time you finished that, the general purpose solution would be faster.

> (check out the dominance of graphics in area and internal bandwidth on the iPad Pro chips -- it calls to mind the Alto's explicit tradeoff of bus bandwidth and screen refresh).

I assume you mean Die Area? Which isn't all that "dominant" if you look at Intel U Series Chip with near 50% of its die area goes to GPU, and even more so in Icelake.

> The real question is the rest of the silicon (peripheral controllers like TB etc which they also get from their Intel deal).

This is one of the reasons I think the 12" MacBook moving to ARM makes strategic sense - with a single non-TB USB-C port, it's already on par with the iPad Pro. (Technically behind, since the iPad has a 10 Gbps port and the MacBook currently only has a 5 Gbps port.)

And I have a hard time sussing why Apple would have seemingly abandoned updates if they're not moving it to ARM.

>As for the tired trope of "As much as Apple has neglected pros" -- I'm tired of hearing that. Yes of course their mix isn't perfect for everyone but holy cow, my MacBook Pro has 4 40GPS TB ports

Yes apples support of high bandwidth ports has always been a selling point for pros. I can also mention their printer driver stack is superior, their audio driver stack is superior, their computers have good audio, their displays have consistently accurate colors, they are early adopters of qhd/5k/6k and offer computers with such displays at a steal of a price, osx is unix-like, there is various exclusive propietrary software, etc, etc.

When I say "neglected pros" I mean it though. That trashcan mac pro sucked and the release cycle of the mac pro has been awful. The macbook pro went from being the fastest WINDOWS laptop to running into worse and worse thermal throttling issues while being saddled with a crap keyboard. The pricing has actually gotten worse relative to other brands and the quest for thinness is causing TCO to creep up due to lack of repairability/user servicability. Apple smacks of focusing on their luxury image with their thin/light obsession and not enough on their prosumer roots.

Yes the improved portability is nice but the biggest jumps were years and years ago and Apple (and other brands) just seem to be getting stupid now.

Real question. Wouldn’t a video editor lean on GPU ?

There's no general answer to that. For example the MPU could have a set of vector operations that use a special range of memory not mapped by the cache and that has its own path to the MPU. Those instructions could conceivably be faster (or have a different power profile) than GPU for certain tasks.

I say "MPU" rather than "CPU" because I think of the CPU in a more traditional sense (ALU+register sets) while I think of system design as encompassing a whole range of functional elements which can include computational, memory, etc. Even within the CPU these days you'll find very complex behavior including speculative execution, various shadow registers and register windows etc.

The comment seems to suggest some special secret sauce so damn specific to the x86 Arch that final cut pro simply stalls without it.

This is inaccurate. Video editing - a DSP heavy compute scenario, probably benefits from a few SSE/SIMD instructions in x86, and possibly a bigger L1/L2/L3 cache in desktop grade Intel processors. None of the stated features are unique to Intel, and an ARM based SoC can easily incorporate similar techniques. Also, current ARM SoCs from Apple target phones and iPads, which automatically necessitates tradeoffs on inclusion of higher capacity L1/L2... caches & novelty accelerator instructions, not just for battery imposed power restrictions, but also based on use cases. The iPhone isn't designed for final-cut-pro, meaning it's CPU isn't designed for it either! But that doesn't mean anything is lacking in the instruction set (ARM)

Even X86 chips aren't really X86, they internally compile down to a different instruction set that is more optimally executed. Technical competition between architectures is hardly relevant now. It's more about building a developer network and access to partners with experience with the architecture.

There's a lot more to the design of an MPU than its instruction set (as you point out yourself by discussing cache), different mixes of functional units and different paths to memory for example.

iMovie already ships on iOS and does roughly all the things Final Cut needs to do using GPU acceleration (which Apple also designs).

I wouldn't be surprised if a heavy duty Mac Pro-class ARM chip from Apple looks like AMD's Epyc, with an array of smaller 5-7nm ARM cores surrounding a larger 12-14nm bus core.

Apple and AMD both use TSMC and this fab technology is apparently ready for prime time.

It would also make sense from a manufacturing standpoint to use a slightly modified phone core in parallel for their poweruser desktop refreshes rather than design a significantly different CPU (otoh Apple seems to have no problem leaving the Mac Pro to languish for years at a time).

They might even get better yields by fabbing a single core with both shared-MMU and the phone SoC features and then disabling one or the other if there are defects.

Given how smooth Apple's transition from PPC to Intel was, and how much experience Apple has with ARM in their portable lines -- if/when the complete transition to ARM happens it'll probably be a brief blip on everyone's radar and likely increase competition both price and performance-wise in the desktop sector.

What's stopping Apple from adding hardware-level emulation to their SOC's, even if it's only partial functions, to ensure cross-compatibility doesn't take a serious toll on performance? x86 would be patent-encumbered but I'm sure there are a few creative ways to reduce that burden.

At the time that Apple went from PPC to x86, x86 had a significant performance advantage such that emulation wasn’t a big deal. Currently, there is no such advantage. In addition, many professional Mac programs make use of SIMD instructions such as AVX. Trying to emulate these will further increase the performance penalty. In addition, x86 has relatively strong memory ordering compared to ARM. There may be code that get away with stuff on x86, that will cause subtle bugs on ARM. Again, it is likely professional programs that do this.

> In addition, x86 has relatively strong memory ordering compared to ARM. There may be code that get away with stuff on x86, that will cause subtle bugs on ARM. Again, it is likely professional programs that do this.

I asked on HN in the past how Microsoft intends to solve the problem for x86-32 emulation on ARM that x86 has a stronger memory model than ARM:

> https://news.ycombinator.com/item?id=14318877

and got an interesting answer:

> https://news.ycombinator.com/item?id=14320799

To put it shortly: the Qualcomm ARM processors (Snapdragon) seem to be able to also to support a strong memory model which makes this emulation possible.

I guess that Apple should also be capable to build such a feature into their ARM chips.

This should not matter for an x86 emulator?

Yes it doesn't matter for the x86 emulator but it matters for the humans using it. Every single difference between the target architecture and the emulating architecture costs you performance. In a CS centric world that is completely disjoint from physical laws it may not matter but if you have infinite time why waste it on waiting for an emulator, why not just rewrite the software in the first place? Unfortunately we are physical beings with limited time. If the emulator isn't fast enough then no one is going to use it.

Sure, but it won't cause "subtle bugs" as the parent comment points out. It'll just make emulation a bit slower.

It's worth bearing in mind the phenomenal level of expertise that Apple have in ARM SoC design. The A12x is in many respects competitive with u-series i7 processors, despite a significantly lower TDP. The A12 Bionic has a vast performance advantage over any other mobile SoC. We don't know what they could do with a much bigger die and a much bigger power budget, but my expectations are high.

It's pure speculation on my part, but I wouldn't be hugely surprised if the first ARM-based MacBook could match the performance of the previous Intel-based machines when running emulated x86 code and substantially outperform them when running native code.

Qemu performance when emulating other cpu arch. is not good. A lot of fast virtualization we are used to is done by the CPU and is all x86. I think it would be harder to get comparative performance software emulating x86 on arm.

Pure speculation on my part too.

> It's pure speculation on my part, but I wouldn't be hugely surprised if the first ARM-based MacBook could match the performance of the previous Intel-based machines when running emulated x86 code and substantially outperform them when running native code.

To me, this would be highly surprising - in particular if we are talking about x86 code that uses AVX instructions. If you want evidence, just consider the performance difficulties that x86(-64) emulators for game consoles that do not use x86 processors such as PS3 or XBox 360 have.

I can't honestly accept that the transition was "smooth". Devices that used to work and used to get updates simply stopped at one point. Because Apple likes to couple OS updates and app updates, and also believes backward compatibility is for [not their customer], I had to talk a grad student down when he sent his thesis to a department chair who opened it, saved it in a non-compatible version of Pages, and sent it back. He could not open that file without upgrading his...2 year old computer?

The transition wasn't smooth unless you had a corporate backer who paid for your milti-thousand-dollar hardware regularly.

> Devices that used to work and used to get updates simply stopped at one point.

Which devices? I kept using my G5 iMac until 2008 without any issues and with regular OS updates.

> Pages

From what I recall, and perhaps what I'm thinking of happened further down the track, Pages had issues in spite of changes to hardware, not because of it. Apple pared back the functionality of its office software when it transitioned from paid to free software, breaking some of the formatting features.

"the first ARM-based Macs could come in 2020, with plans to offer developers a way to write a single app that can run across iPhones, iPads and Macs by 2021"

Although this may very well be true and somewhat beneficial (see the related story about "unified Mac/iOS Apps from Ars Technica), the existence of "fat binaries" on Mach means that having multiple CPU architectures does not prevent shipping single combined binaries (for some definition of "single") today.

NeXTstep shipped single binaries for 4 architectures (68K, Intel, HP PA and SPARC), and due to the app-wrapper architecture, you could actually add the binaries for different OPENSTEP platforms as well, for example Yellow Box for Windows and OPENSTEP for Solaris.

Not sure anyone actually did this, but you could easily have had an actual single program supporting 3 operating system and 4-6 CPU architectures (if you include the 88K and PPC systems they had in the lab).

Just imagine the ire once HN finds out that the Slack client contains the binaries for the Chrome engine not just one, but 3-4 times over!

That would be humorous for sure. Unfortunately (fortunately?), the App Store already deals with multiple architectures seamlessly. Apple mobile devices are a mix of arm7, arm8 and arm64.

The Swift Playground app on the iPad has for years allowed you to save, compile and run files containing any arbitrary Swift code you've felt like writing (though no access to Frameworks of course): the arm-based compiler must be very solid by now.

Really, it seems that success or failure hinges on how open the platform is (and if they have hardware virtualization).

> though no access to Frameworks of course

Swift Playgrounds gives you full access to frameworks.

Unfortunately no ARM vendor is interested in open platforms. Therefore a move to ARM laptops or desktops will be a step back in my opinion. Google's chromebooks can only run chrome. Windows on ARM can only run UWP apps and win32 only under emulation. It wouldn't surprise me if the new "iOS" on the macbook will only run iOS apps.

Another thought: The move to higher level frameworks (UWP etc) as official APIs makes it harder for languages to interoperate compared to a simple C api and therefore vendors have even more power over their platform.

> Windows on ARM can only run UWP apps and win32 only under emulation.

You can compile C++ Win32 apps to ARM64 for WoA: https://blogs.windows.com/buildingapps/2018/11/15/official-s...

The A12X is already comparable to some Intel CPUs in terms of performance. Yet its power and thermal budget is tiny. The Macbook Pro 13" has an 83 Wh battery [1], while the iPad Pro 12.9" only has 36 Wh.

What I like to imagine is an ARM Macbook with the equivalent of two A12s. That will give you an outstanding performance with better battery life. You'll also get further growth potential that Apple has demonstrated year over year, compared to Intel CPUs, which have stagnated.

I'm terribly excited about this. And yes, getting your Docker images to run on ARM will be a bit of a drag, but in the long term, this sounds like the future.

[1] https://www.apple.com/legal/more-resources/docs/apple-produc...

What if they start rolling the locked down sandbox features into MacOS?

If they do, what does that have to do with ARM?

Unified hardware makes unified software easier.

Then a large part of the Mac userbase, especially anyone doing any kind of development, is going to drop the Mac platform. This is also the main reason the iPad Pro doesn't make larger dents into the laptop market. Development and even file transfer between apps is very limited.

It's getting better. I wrote a piece on immediate file transfer between apps to simulate "live painting" from one app into another. I can see iPad getting there, but productivity app developers are slow to adopt the iOS file system introduced some time ago.

https://codea.io/blog/whats-next-for-ipad-creativity/

they already have- you can still unlock it if you have admin but ve default you’re restricted to signed and sandboxed mac app store apps.

The A12X is a ten billion transistor 10 watt 7nm chip. The Intel chips have fewer transistors, a 10nm or 14nm process, and some of them have a similar power budget.

The A12X is amazing but you cannot have your cake and eat it too.

Why do you think it's comparable? I've never seen any cross-platform benchmarks. Except Geekbench, which isn't worth taking seriously.

It's plausible it's competitive with modern x86 stuff. I just haven't seen any evidence one way or the other.

Anandtech’s review shows that it is comparable in a number of benchmarks including SPEC https://www.anandtech.com/show/13661/the-2018-apple-ipad-pro...

>The Macbook Pro 13" has an 83 Wh battery [1], while the iPad Pro 12.9" only has 36 Wh.

What has the size of battery in Mac and iPad got to do with its SoC / CPU. The A12X is only comparable to Intel under a sustained Sub 10W workload. We have yet to see how it will perform in the higher TDP range. Scaling CPU TDP up or Down is not a simple task.

My only worry is if they will lock down the Macintosh to only allow signed or, worse, apps from the App Store. If its just a move to ARM then cool, but I still want to have 32GB of memory and some decent storage. That ship has sailed, I guess, but I really want a Mac Pro worthy of the name. I miss the G4 case.

Yeah, I agree. I seriously doubt they will take the inconvenient open-ish intel architecture to arm.

That would mean disabling the ability to use all command line tools not included with the base system. What would Apple gain from doing that? They would certainly alienate a large number of power users in the process.

By default, macOS Mojave does not let you so much as ls many folders in your own home directory.

Can you elaborate more?

For example: https://i.imgur.com/hB4pPZd.jpg

Macs are heavily used as development machines, so it won't be locked down for programming. It will be the first machine with programming capabilities with awesome battery life.

What's even more fun is that it can mean that some companies switch to ARM servers if their environment works well for development (just what Linus told that it won't happen)

Will I be able to disable SIP when I need to?

I wonder why this is perceived to be a problem in the first place. Company A (apple microsoft google) wants to move to ARM from x86. x86 has all the applications that existing users want. When they move to ARM they have 0 applications. As a response they try to offer you to use ARM apps from their existing store but then they lock down the APIs that made the x86 apps possible in the first place. In other words they aren't even giving the platform a chance to grow. They expect it to be usable from the first day on. In my eyes this doesn't make any sense at all. It only took 12 years for the app market to become this big and the vast majority of apps were developed in the latter half. Why shouldn't it take less than 6 years to completely transition the old apps to the new ARM platform? However no one is willing to wait that long for some reason.

They promised Mac Pro successors in 2019, and Mac to ARM transition in 2020.?

I still think all these are negotiating tactics. The Mac is now primarily a prosumer and pro devices only. Apple should milk it for as long as possible with spec update now and then. The message to Intel's new CEO if you don't give us better pricing, we will move to ARM ( along with our own 5G Modem ). My guess is that since Intel's new CEO is a Finance Guy, lowering prices isn't something he will do. And 5G Modem is also one of those business that makes little to no margin from Intel's perspective. Intel's ex CSO Aicha Evans, the person responsible for getting the Modem business moving despite internal pressure against it, has also left Intel.

Or may be Apple really do have a Grand plan. Apple is one of the largest buyer of servers. May be the ARM N1 allows them to go top to bottom ARM. From Devices to Servers. ( And the return of XServe... I can only dream of it )

If Apple returned to servers, it should be in the form of a semi-headless version of macOS optimised for virtual machines.

I don't think it's negotiating tactic, or any complex strategy. I just think Apple look at the MacBook and Air and see them as mobile devices far closer in market fit to the iPhone/iPad than the MacBook Pro. And given that they're already manufacturing their own chips with the power/perf profile as needed for mobile devices, why not use them?

It make perfect sense for MacBook and MacBook Air, but neglecting MBP, Mac mini, iMac, iMac Pro, and Mac Pro. Creating a Platform which support ARM in the low end and x86 in the high end is far more expensive than whatever BOM cost that is saved from using their own designed SoC. That is unless Apple goes back to Universal Binary.

> They promised Mac Pro successors in 2019

I don't think they ever did promise that. They made the original announcement in 2017 and only announced "not 2017", they never actually committed to a date.

https://techcrunch.com/2018/04/05/apples-2019-imac-pro-will-...

Unless the Reporter misinterpreted what he said.

One more stone into their garden - they got Infineon's modem business for truckloads of money, despite it already being dead. Then, they sank even bigger amounts of cash into it for nothing. They all wanted to get "megaclients," ignoring the fact that nobody of them will use a standalone modem. They only had chance to get it off the ground in China, but they never seemed to even acknowledge the existence of Chinese domestic market.

I fear a fast deprecation for x86 support like in [1].

After releasing the first Intel Macs in 2006 we already saw the last OS X release with PowerPC support only one year later in 2007. I believe a Mac has a longer lifetime than a smartphone or tablet and I hope that the Apple ecosystem will not leave the Intel devices behind so fast.

The other uncertainty is the upcoming move to Marzipan apps. If its full release becomes somewhat ARM-exclusive, we might have the same risks as with Windows 8 and their Metro disaster. In the case of an unified iOS/macOS-Hybrid these ARM Macs might have no fallback anymore to the already established macOS ecosystem. (like Windows RT)

[1] https://en.wikipedia.org/wiki/Apple%27s_transition_to_Intel_...

I think that's overstating what happened. What I'd look at is the first release of MacOS that didn't support the old hardware. That was Snow Leopard in 2009. At that point, PowerPC users couldn't upgrade to the newest OS. Apple released the last security update to Leopard August 13, 2009. If you had bought a Powerbook May 15, 2006, the day before they announced the MacBook, you would have gotten three years and three months out of it before you stopped getting security updates. These days people wait longer than that to replace their computers, but the computer was definitely not a brick after a year.

And to put things in perspective... Apple announced in June 2005 that they were going to phase out PowerPC, so anyone actually buying a Powerbook in May 2006 knew that they were going to get a reduced lifetime.

Wikipedia's timeline lays it all out pretty well:

https://en.wikipedia.org/wiki/Apple%27s_transition_to_Intel_...

There was 4 years from the official announcement to dropping support in the latest OS and 7 years between the official announcement and the last official software release.

Personally speaking I hope they go faster.

The faster they rip the band-aid off the better. Apple only does this because they can. They can only do this because they control so much of the ecosystem. This is a good thing. This is a benefit of them holding control over so much of the apple ecosystem. This moves the industry forward.

I don't even use apple stuff because I don't like the monopoly. But that doesn't mean I can't reap the rewards and f a faster moving industry.

Apple also doesn't think twice about giving the finger to anyone who actually depends on old hardware, peripherals, or software... or software/peripherals that only begrudgingly update to explicitly support the latest and greatest platforms. These are often the kinds of things with a far longer useful life than the computer itself, and/or things that work fine for their purpose and don't actually need upgrades.

This is one area that Microsoft has generally done far better, though that may not hold true forever.

I don't think that it's the control of the ecosystem that affords Apple to dump x86. It's mostly that they can afford it. Their make money from iPhones. Their computer market share is still <7%, much of which is just hipster kids browsing the web that will not be affected much by the switch. I doubt Apple is the leading vendor even in the "creatives" segment of computer market. The bottom line is that they get to screw their computer users without really jeopardising their business.

I've been playing with a Windows ARM64 laptop and it's weirdly sluggish mainly because I think ARM IO and GPU cannot compete with Intel's offering. You can run benchmarks and the CPU seems decent for a laptop, but it's all the other things that make a great user experience.

I'm skeptical that Apple would do this to replace Intel as an option, especially in the Pro line-up. This is either a move for a co-processor to aid in better battery, or a lightweight, LTE/5G connected laptop that exists on its own. shrug

I'm not sure it will work for some tasks at all. Specifically A/V editing may suffer, adobe tools in general likely won't see the light of day, and the day to day software won't be a clean migration most likely.

It could actually be a great opportunity for Adobe to pair with a Linux vendor (IBM, Canonical) to create a first class supported environment, if they have to do the architecture migrations anyway. I also think that Apple should probably create a gui toolkit as an alternative to electron for mac supported apps, or possibly a react native option.

It will be interesting, but if they kill their pro lineup, I don't know they can compete, too many are already using 6-7 year old mac pros, and this will kill hackintosh which is what a lot of pros have gone to.

Adobe is already porting their software to ARM architecture. I imagine opening a billboard sized PSD would be painful, but I could see small little icon assets and making tweaks would be a perfectly valid lightweight activity.

https://www.macworld.com/article/3313881/software/adobe-intr...

I don't know how large is "billboard sized", but iPad Pro with full Photoshop CC can open 3GB 12000x12000 PSD files without any lag.

https://petapixel.com/2018/10/30/apples-new-ipad-pro-can-edi...

I may be mis-remembering, but I thought Adobe was re-mangling all their apps to use web tech under the covers?

There's a lot that can use web tech... I think we're at a point where image editing is probably an option, I don't think we're anywhere near there for video editing or computer generated 3d graphics.

They’ve also been porting code to iOS this whole time

That laptop doesn't have an Apple CPU. Apple ARM silicon is competitive with Intel today. In a few years it simply won't be possible to buy a PC that's performance competitive with an ARM-based Mac.

Doesn't this kill Boot Camp entirely?

Back when I used to encourage people to buy Macbooks (2010-2016), the ability to boot into Windows natively to run programs with no OS X equivalent usually gave them the level of comfort necessary to jump ship.

Losing Boot Camp is going to be a big loss.

Well, there is a Windows 10 for ARM, so maybe that would be available.

I actually wonder what a big loss it would be. I was one of those who switched because of the availability of Boot Camp and have long since left Windows behind. But how many native apps do people really use these days, compared to web sites? I genuinely wonder.

Almost all serious games are Windows-only native apps, or at least are at launch.

Also, there's always going to be something you need to run that's a Windows-only binary. You may not need to run it frequently, and you might only stumble upon it every few years. It might be a utility to interface with a specific piece of hardware, or some program that performs a very specific and/or niche function. But there will always be something.

Windows 10 can run on ARM. So they could keep it around.

Obviously it wouldn’t run most of the software people actually care about.

But they could keep it.

Windows 10 on ARM does realtime binary translation of x86-32 programs, so it can still run them, though speed may be an obstacle for some programs.

I didn’t know that.

Windows on Arm runs most software people actually care about. The only thing it can't run is 64bit x86 apps. And those can be ported to arm64.

How's game compatibility?

I think, for me, the biggest fear is using an ARM-based Mac to build cloud-based software that runs on Linux x86.

Much of my development environment emulates production in Docker x86, but an ARM-based development environment would have to emulate x86, no?

Alternatively, this could make for building apps in ARM cloud more viable...

Docker is fully arm compatible, so it should be very easy to run these apps on ARM cloud servers. In fact, as ARM begins to take over the cloud, this could sell a lot more MacBooks for developers.

AMD64 binaries inside a docker image don't spontaneously become ARM binaries if you run them on a different machine.

You’re right, but there is a very healthy ecosystem of Arm-compatible Docker images and tools already. That definitely gives developers a head start in adding Arm support. Depending on their dependencies, they might not need to do anything more than change labels in their Dockerfile and rebuild.

I wouldn’t call it healthy. Every time I have an inkling to run k8s on my rpi cluster I find out that there aren’t arm images for many of the tools I want to use, and many of the arm images that exist are hard to find (Docker hub doesn’t/didn’t support searching via arch) or aren’t actively supported. It would be great if everyone did make arm builds for their software, but that’s not been the case in my experience.

There's a chicken-and-egg thing here. It'd probably shift quickly enough if there were enough devs who wanted it, but that wouldn't (as I noted further up) change the existing blobs. Folks impute magical powers to container systems and I am required by Hacker News civil code §13.3(7) to nitpick it obnoxiously.

For comparison, IBM has teams of folks roaming the opensource world looking for things to port to POWER and ppc64le architectures. If you run a successful enough project they show up and start submitting patches.

There is search by architecture on Docker Hub now.

No, but many images used in the FROM directive do support ARM, so if say you start with an Alpine base image, and then do "apk install nodejs," and then run some Node app code, you don't have to modify a thing for ARM. Just clone and build as usual.

I know on Linux, you can use qemu as a compatibility layer to run binaries for different architecture. I would expect that it would be relatively simple to do something like that on Darwin. Possibly even literally using qemu; I don't use Apple products personally, so for all that I know support could already exist.

If you're doing everything on Docker anyways it kind of doesn't matter, as Docker already runs on top of a linux virtual machine on OSX. As long as Apple puts in the effort to bridge their hypervisor framework[1] this should continue to work.

[1] https://developer.apple.com/documentation/hypervisor

The current Linux virtual machines use the x86's virtualisation instructions to run at almost native speed. That is not possible if the virtual machine has a different architecture to the host, and execution would be much slower.

Windows on ARM performance for x86 emulation is about half that of native code - I'd expect comparable performance from Apple, though from a higher ARM baseline than Snapdragons.

If you’re using Docker you’re probably not using a Mac anyway, performance is already terrible.

Agreed, Docker on Mac performance is abysmal. Writing from a container to a shared volume yields sub-10MB/s write speeds and full load on at least two cores via hyperkit. I get that translating I/O between file systems is expensive but even Windows does this better. It's the number one reason why I'm looking into switching away from macOS right now.

If you click your own link, you'll quickly notice that the Hypervisor.framework API is incredibly x86-specific, for example one of the methods listed take parameters of type "hv_x86_reg_t".

Hypervisor.framework in its current design has nothing to offer for cross architecture emulation.

Even if this api was changed to provide arm hypervisor functionality, at best you'd probably be looking at an arm-linux-only variant of docker. Not very useful if you are planning on deploying to x86/x64 linux servers.

“For Intel, of course, it would mean the loss of a significant customer, albeit probably not a huge hit to its bottom line”

ARM could well become a huge breakthrough for tech. For the first time, it’s possible to license and customize silicon to purpose with much less overhead. We’re used to the usual combination of specialized processors (cpu/gpu), but this will open up further specialization - crypto (proc-bound), file systems (possibly some parallelism, need for gobs of flash), AI, UI (proc-bound, benefits from high frequency and no interrupts), who knows what else.

It has already started - most flagship phones these days have a litany of specialized coprocessors (for biometrics, neural networks, imaging, etc).

Don't they have special chips just for decompressing specific video formats? Ie. Why I noticed some time ago that suddenly phones stopped chugging power just to watch YouTube.

Not sure about special chips, but yes, most processors have hardware encoding/decoding for common video formats.

Yes. Those "coprocessors" are special circuits on the SoC, typically somewhere on the CPU sillicon.

"ARM could well become a huge breakthrough for tech."

???

Arm has been around since 1987 Runs billions of devices. Its always been possible to license arm, at a cost.

Now there are free open source architectures which are suerly more interesting for custom silicon than paying huge license fees to Arm Holdings.

RISC-V is picking up steam in this same front.

Despite having said for years that ARM based macs will be a thing, I no longer think this is the case.

For Apple, it's simply not worth it. They've been conspicuously moving development resource from the mac to iDevices for the last ten years and the mac is increasingly becoming an (actually very good) development platform for the iDevices in question. I mean, c'mon, the big feature for the last release of macOS was a 'dark' skin ... and from the hardware side all we want is a keyboard that doesn't shit itself.

On the other hand the iPhone on it's own is one of the largest businesses on earth, and is under sustained attack by Google/Samsung/Huawei - the latter two of which are prepared to openly 'cheat' by any means possible. Under such circumstances would you throw significant resource at a dying market, ~10% revenue, where Intel are quite prepared to do the majority of the heavy lifting for you?

This is actually an argument for Apple to switch entirely to ARM. If they could consolidate engineers, it could continue to invest in Mac without needing crazy growth numbers to justify it.

True, but the initial cash outlay is immense. Sure, Apple can deal with it. But is it worth it?

Why would they do this? They'd need a new line of ARM variant CPUs to meet the various performance points of the different macbooks and imacs. And they'd be amortizing those costs over a rather small (for them) number of units.

And that would do very little to address the costs of maintaining the OSX software stack, very little of which is CPU specific. Most of those costs are in maintaining a rather different model of UI interaction, software installation, and backwards compatibility.

My guess is that they have developed this capability in-house as a form of insurance, and will keep it around and alive as a way of keeping their Intel costs reasonable.

Given the success of the last CPU arch transition, there's honestly no reason why the transitional state couldn't be semi-permanent with powerful desktops sporting top Intel chips and ultra-light laptops running souped-up A-series chips from Apple. All it takes is for developers to be producing multi-architecture binaries, something macOS is already good at and something developers were doing for years not that long ago.

Remember the WWDC 2020 keynote when they said: "Almost all of your Mac apps will compile for the A14 chip with zero code changes!"

The pricing improvements that they get on another round of Intel processors might well be worth the entire chip design cost, especially when they are using their ARM chips in the iPad line anyhow. Although by now, the "give us good prices or we'll leave" factor might already be priced-in.

For who it creates uncertainty?

Application developers and users?

Well, at the very least, Intel!

But until there is more information, most users and application developers won't really have to worry. This is all still very speculative at this stage.

So what's stopping Intel from going ARM?

Modern Intel processors aren't X86 internally anyway, so why can't you just slap an ARM decoder on an Intel core?

I'm curious, could we expect Linux support for Apple designed Arm?

As much as for running Linux on the iPhone / iPad I bet.

Maybe in 2025 if you're lucky. Apple sure as hell isn't going to release opensource drivers like intel or AMD are doing.

With Bootcamp: Very likely.

I'm not so sure if they'll include it this time, though (still I tend towards yes, but it also will depend on Windows ARM's success).

Current Macs with Bootcamp are already basically useless for running Linux. It is not technically impossible to run but might as well be. The T2 SSD controller actively prevents access by any OS that is not either MacOS or Windows, even with secure boot disabled.

I don't think Apple would be nearly as open this time as they've been in the past. It'll probably be nearly as locked down (in terms of load) as the iDevices are. Not only that, but it will put the final nail in the Hackintosh should they deprecate x86 support.

ARM based Macbook running iOS might be something to start with.

As travel companion Macbook style device is better than tablet (IMO). Proper keyboard and design which allows it to be used on lap.

I would really like to see Apple’s take on Lenovo Yoga style device.

This really is a non-story.

The future is by definition uncertain.

Reply on news.ycombinator.com