Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Will Apple lock ARM Mac down? Probably.
Will ARM be the reason for the lock down? No.

What may happen is that apps that have been submitted and sold in the Mac App store could be recompiled for ARM - maybe by Apple and without the developer doing any work (especially if the developer used Apple's tools.) At that point - ARM apps that are available will only come from the Mac App store (at least initially) and could be locked down.

But there are a lot of apps that developers sell or distribute on their own (either through their website or through other distributors like SetApp) that may always be Intel-only.

So, it's quite conceivable that consumer-focused Macs (iMac, Macbook/Air) could be ARM and only get apps from the Mac App Store, while more Pro-focused Macs (Mini, iMac Pro, Macbook Pro, Mac Pro) stay with Intel and can get apps from anywhere (Mac App Store or through other sources) and have more choices available.

But my question has always been - why go through the trouble for a consumer-focused, locked-down ARM-based Mac when you can expand iPadOS for more Mac-like functionality, and provide features that would be difficult for the Mac (touch-screen controls, 2 in 1) all the while using the current, numerous iPad apps that already exist with no re-compile?
 
What may happen is that apps that have been submitted and sold in the Mac App store could be recompiled for ARM - maybe by Apple and without the developer doing any work (especially if the developer used Apple's tools.) At that point - ARM apps that are available will only come from the Mac App store (at least initially) and could be locked down.

But there are a lot of apps that developers sell or distribute on their own (either through their website or through other distributors like SetApp) that may always be Intel-only.

So, it's quite conceivable that consumer-focused Macs (iMac, Macbook/Air) could be ARM and only get apps from the Mac App Store, while more Pro-focused Macs (Mini, iMac Pro, Macbook Pro, Mac Pro) stay with Intel and can get apps from anywhere (Mac App Store or through other sources) and have more choices available.

But my question has always been - why go through the trouble for a consumer-focused, locked-down ARM-based Mac when you can expand iPadOS for more Mac-like functionality, and provide features that would be difficult for the Mac (touch-screen controls, 2 in 1) all the while using the current, numerous iPad apps that already exist with no re-compile?
"But my question has always been - why go through the trouble for a consumer-focused, locked-down ARM-based Mac when you can expand iPadOS for more Mac-like functionality, and provide features that would be difficult for the Mac (touch-screen controls, 2 in 1) all the while using the current, numerous iPad apps that already exist with no re-compile? "

My thoughts exactly. Keep expanding on the capabilities of iOS / iPadOS for mainstream consumers while the Mac becomes more of a niche professional tool.
 
Large developers have been using Xcode for a long time already and were not affected. These same developers, having already prepared for Catalina are extremely well prepared for a 64 bit ONLY CPU now. Just recompile and tweak.

This is a major change that requires more than a checkbox and a recompile for major developers. It's new hardware to test for and maintain. Once-dependable Mac developers like Blizzard have already begun to ignore the Mac in new major releases and may be persuaded to reconsider any Mac support beyond minimum-effort iOS ports. Other developers that depend on stable platforms that don't have a lot of churn, such as DAW and VST developers, will be affected--some of them are only now getting around to officially supporting Catalina.
 
Microsoft has always worked with the large game development firms to keep things functional. Don’t get me wrong, I despise Windows with a passion, but thanks to Microsoft, it is definitely a gaming platform, and can be trusted as such.
The contrast between Apple and Microsoft is not about gaming, but legacy support. Microsoft has always focused on legacy support also due to legacy applications being a huge asset in their customers lock-in. This is not something specific for games, but in general for all kinds of software.

Apple is much less concerned in obsoleting legacy application, be them games or productivity suites or whatever.
 
What may happen is that apps that have been submitted and sold in the Mac App store could be recompiled for ARM - maybe by Apple and without the developer doing any work (especially if the developer used Apple's tools.) At that point - ARM apps that are available will only come from the Mac App store (at least initially) and could be locked down.

But there are a lot of apps that developers sell or distribute on their own (either through their website or through other distributors like SetApp) that may always be Intel-only.

So, it's quite conceivable that consumer-focused Macs (iMac, Macbook/Air) could be ARM and only get apps from the Mac App Store, while more Pro-focused Macs (Mini, iMac Pro, Macbook Pro, Mac Pro) stay with Intel and can get apps from anywhere (Mac App Store or through other sources) and have more choices available.

But my question has always been - why go through the trouble for a consumer-focused, locked-down ARM-based Mac when you can expand iPadOS for more Mac-like functionality, and provide features that would be difficult for the Mac (touch-screen controls, 2 in 1) all the while using the current, numerous iPad apps that already exist with no re-compile?

There's something you have to know: AppStore and other distribution method does not make any major different for Mac apps.
AppStore only limit access to some high privileges API/actions and that's it.

Usually if you find a app that's both in AppStore and direct download from developer's website you will find out they are exactly the same or the only different is lacking some feature that require admin permission.

If Apple lock everything down then your not in AppStore Intel app will gone also.
If not then developer can distribute ARM version of their app on their website just like how they distribute Intel version now.

There's nothing "Intel-only" from a software developer's vision. That's for project manager and investors and not related to anything technical.



BTW: Apple did not mandate "BitCode" aka "LLVM IR" for their Mac AppStore. And by now LLVM IR is far from perfect to recompile x86 optimized IR to ARM binary.
So online recompiled will not happen for Mac AppStore.

This online LLVM IR recompile only happened once for Apple Watch Series 4. When they have to compile a ARM64_32 version of all AppStore Watch Apps.
[automerge]1582744535[/automerge]
This is a major change that requires more than a checkbox and a recompile for major developers. It's new hardware to test for and maintain. Once-dependable Mac developers like Blizzard have already begun to ignore the Mac in new major releases and may be persuaded to reconsider any Mac support beyond minimum-effort iOS ports. Other developers that depend on stable platforms that don't have a lot of churn, such as DAW and VST developers, will be affected--some of them are only now getting around to officially supporting Catalina.

The good news is if they already support Catalina they are already in good shape for arm.

32bit and 64bit for macOS is much more different than you think.
Apple did not support Carbon in 64bit and they locked down Cocoa API for 32bit.
So 32bit app and 64bit app for macOS looks like from two totally different OS.

When everything went 64bit it most likely will be just a checkbox and that's it.
This transitioning is much easier than from x86 to x64 where data sizes are different. (And a lot of code using sizeof(type) rely on them being exact same number)
There's no secret that ARM64 defined same data sizes as x64 for the source code compatibility.
 
Last edited:
expand iPadOS for more Mac-like functionality, and provide features that would be difficult for the Mac (touch-screen controls, 2 in 1) all the while using the current, numerous iPad apps that already exist with no re-compile?


Agreed. The third-party iOS app wasn't able to utilize the menu bar for extending its app capability on a device like an iPad.
 
Adobe got photoshop ported in 2007 (CS3).
Microsoft got Office ported in 2008.
[automerge]1582739230[/automerge]


Just virtualize everything you need in the cloud.
Be it public cloud or private cloud.

That's normal in enterprise environment.
There's not reason to bind fresh new client side gadgets to 30 years old technology debt.
It would still need to be rewritten and performance is a huge issue when we don't even have gigabit ethernet available. Cost is still huge....
 
all 64-bit apps anyway
All 64-bit apps? Every app that was available 10 years ago has been updated? Wasn’t aware of that. My bad.

I don’t think Apple will provide a transition. It could be that they will. If they do, it won’t hurt my feelings, it’ll be interesting to see the solutions they come up with though.
 
It would still need to be rewritten and performance is a huge issue when we don't even have gigabit ethernet available. Cost is still huge....

Nothing need to be rewritten.
As nothing was rewritten last time. Do you really think Photoshop was rewritten from ground up for Intel last time? And why that is related to ethernet? What performance you are talking about? Did intel perform worse than PowerPC?

Recompile and fix some small issues are all you need for a CPU arch change. Most software developer will never touch CPU arch dependent code at all for their whole life.
 
Nothing need to be rewritten.
As nothing was rewritten last time. Do you really think Photoshop was rewritten from ground up for Intel last time? And why that is related to ethernet? What performance you are talking about? Did intel perform worse than PowerPC?

Recompile and fix some small issues are all you need for a CPU arch change. Most software developer will never touch CPU arch dependent code at all for their whole life.
You're kidding, right? Of course things needed rewritten, even most likely a good part of photoshop when it went from 32-bit to 64. But I'm not concerned with photoshop, I'm concerned with my corporate apps and to move to a cloud based paradigm would definitely require a rewrite. As for ethernet, I was talking about public cloud, it's not doable here because of no internet connections fast enough. You could do it local, but why, what does that buy you? Like I said it still has to be rewritten and that costs big bucks, and then there's the hardware, software, and licensing to run your own cloud. Big big bucks. We don't make money off what we write or support here, and modernizing it will make us no more money, so it's extremely hard to get the guys that control the purse to do that.

And btw, I didn't have any Mac's when it was powerPC based, so I don't remember that transition.

We're mainly a Windows shop too, so what is my incentive to buy a totally new Mac with an ARM processor if it can't run the old stuff? It would be the same for Windows too, if they come out with an OS that can't run the old stuff, there's no way I'd buy into it.
 
  • Like
Reactions: cardfan
You're kidding, right? Of course things needed rewritten, even most likely a good part of photoshop when it went from 32-bit to 64.

Going from 32 bit to 64 bit requires a lot more work than switching CPU architectures for almost all apps. It is very unusual nowadays for any code to be CPU-dependent. That's one of the reasons you can click a checkbox and compile your apps in Xcode so they run on Mac - when checking a single box doesn't work it's not because of differences in CPU architecture, it's because differences in the OS's support for specific SDKs.

Apps like MS Office, for example, will not need to be "rewritten."
 
Going from 32 bit to 64 bit requires a lot more work than switching CPU architectures for almost all apps. It is very unusual nowadays for any code to be CPU-dependent. That's one of the reasons you can click a checkbox and compile your apps in Xcode so they run on Mac - when checking a single box doesn't work it's not because of differences in CPU architecture, it's because differences in the OS's support for specific SDKs.

Apps like MS Office, for example, will not need to be "rewritten."
Rarely that's the only change between platforms for custom code... (It's not CPU dependent code I'm worried about, we have none that would be affected, but it is OS/libraries dependent)

For the stuff that is CPU/hardware dependent, we just don't change them, they stay on their CPU and OS level. Hopefully you can switch them out eventually for something totally new.
 
You're kidding, right? Of course things needed rewritten, even most likely a good part of photoshop when it went from 32-bit to 64. But I'm not concerned with photoshop, I'm concerned with my corporate apps and to move to a cloud based paradigm would definitely require a rewrite. As for ethernet, I was talking about public cloud, it's not doable here because of no internet connections fast enough. You could do it local, but why, what does that buy you? Like I said it still has to be rewritten and that costs big bucks, and then there's the hardware, software, and licensing to run your own cloud. Big big bucks. We don't make money off what we write or support here, and modernizing it will make us no more money, so it's extremely hard to get the guys that control the purse to do that.

And btw, I didn't have any Mac's when it was powerPC based, so I don't remember that transition.

We're mainly a Windows shop too, so what is my incentive to buy a totally new Mac with an ARM processor if it can't run the old stuff? It would be the same for Windows too, if they come out with an OS that can't run the old stuff, there's no way I'd buy into it.
Nothing need to be rewritten. I explained how compiler works several pages ago. It's really hard to find a programmer that knows how to write CPU specific codes -- trust me you have to pay a lot to get that kind of work done, especially by today's trend of doing everything in javascript.

macOS 32 and 64 bit is a special case as they are using totally different APIs. It's much harder to change from 32bit to 64bit for Mac than changing from x86 to ARM.
You should refer to iOS 32 and 64 transition as that's more close to what a x86 to arm transition on Mac will looks like. A checkbox, some library, small issues here and there (usually stupid/amateur mistakes in the code or hack workarounds) and done.

And also you even don't need to check sizeof(type) issues as ARM64 by default is using LP64, same as AMD64.

If your enterprise software is replying on special CPU and OS then I bet it is not macOS and not for this topic.

If your special software is (surprisingly) written for macOS and lose support for long time then that's already a problem now as Catalina dropped 32bit compatibility.

You do not have to modernizing it and by running it inside virtual machines on the cloud is good enough.
You really do not need gigabit internet to just remotely using a desktop app. The bandwidth usage for Remote Desktop is really low.

And there's already no reason for a Windows shop to buy Mac if app compatibility is your concern.
Intel Windows App will not magically run on an Intel Mac anyway. And as many already point out, porting Windows x86 app to Mac x86 is much harder than porting Mac x86 app to a Mac ARM platform.

You may want to check out how Windows on ARM works now and that might be a better platform for you as it does mostly maintained backward compatibility as a temporary solution.
 
Last edited:
macOS 32 and 64 bit is a special case as they are using totally different APIs. It's much harder to change from 32bit to 64bit for Mac than changing from x86 to ARM.
You should refer to iOS 32 and 64 transition as that's more close to what a x86 to arm transition on Mac will looks like. A checkbox, some library, small issues here and there (usually stupid/amateur mistakes in the code or hack workarounds) and done.

If your enterprise software is replying on special CPU and OS then I bet it is not macOS and not for this topic.

If your special software is (surprisingly) written for macOS and lose support for long time then that's already a problem now as Catalina dropped 32bit compatibility.

You do not have to modernizing it and by running it inside virtual machines on the cloud is good enough.
You really do not need gigabit internet to just remotely using a desktop app. The bandwidth usage for Remote Desktop is really low.

Changing from 32-bit to 64-bit also is difficult because your data structures need to be revisited (especially if you want to allow backward compatibility with old saved data). You almost never want all your variables to become 64-bit, so you spend a lot of time going data structure by data structure figuring out which variables need to be 64-bit and which need to be 32-bit. Then you have to figure out how to handle old data that was organized in binary databases in 32-bit form, often providing a translation layer or a one-time import routine. And then you may have to continue to support 32-bit and 64-bit databases for awhile. It’s a mess. I had to deal with that when working at AMD when the design software I wrote needed to be ported to AMD64, and it was not fun, especially because the size of an “Int” in whatever language you are using may mean “32 bits if you have a 32-bit processor and 64 bits otherwise,” or it may mean “32 bits always” or even “64 bits always, and your code can no longer be compiled for 32-bit machines,” and you may have made assumptions that two data types always have the same size as each other, but now they do not.
 
  • Like
Reactions: MikeZTM
Nothing need to be rewritten. I explained how compiler works several pages ago. It's really hard to find a programmer that knows how to write CPU specific codes -- trust me you have to pay a lot to get that kind of work done, especially by today's trend of doing everything in javascript.

macOS 32 and 64 bit is a special case as they are using totally different APIs. It's much harder to change from 32bit to 64bit for Mac than changing from x86 to ARM.
You should refer to iOS 32 and 64 transition as that's more close to what a x86 to arm transition on Mac will looks like. A checkbox, some library, small issues here and there (usually stupid/amateur mistakes in the code or hack workarounds) and done.

And also you even don't need to check sizeof(type) issues as ARM64 by default is using LP64, same as AMD64.

If your enterprise software is replying on special CPU and OS then I bet it is not macOS and not for this topic.

If your special software is (surprisingly) written for macOS and lose support for long time then that's already a problem now as Catalina dropped 32bit compatibility.

You do not have to modernizing it and by running it inside virtual machines on the cloud is good enough.
You really do not need gigabit internet to just remotely using a desktop app. The bandwidth usage for Remote Desktop is really low.

And there's already no reason for a Windows shop to but Mac if app compatibility is your concern.
Intel Windows App will not magically run on an Intel Mac anyway. And as many already point out, porting Windows x86 app to Mac x86 is much harder than porting Mac x86 app to a Mac ARM platform.
We have very little Mac software, but we do have it, mostly commercial plus some java based stuff. And yes, the break in Catalina pretty much made certain we wont be using any more Mac stuff here. I'm in this topic because I do use Mac's at home too, and I'm concerned for a break in compatibility, pure and simple, especially when it's going to an architecture that I can't see will be any better and probably worse.

And yes, I know not to worry about Windows code on MacOS (without an emulator of course), duhhhhh. If I need a Windows machine, that's what I use...
 
We have very little Mac software, but we do have it, mostly commercial plus some java based stuff. And yes, the break in Catalina pretty much made certain we wont be using any more Mac stuff here. I'm in this topic because I do use Mac's at home too, and I'm concerned for a break in compatibility, pure and simple, especially when it's going to an architecture that I can't see will be any better and probably worse.

And yes, I know not to worry about Windows code on MacOS (without an emulator of course), duhhhhh. If I need a Windows machine, that's what I use...

So that's simple:
Java stuff still runs. And actually good news for you: ARM CPU right now could runs Java much faster than Intel according to specjvm benchmarks.

Old commercial software have to be upgraded. But I guess everyone is moving to web based software regardless of Windows of Mac for quite some time now. That will be a good decision making information for the next time your company purchase new software as web software could runs on everything including phone and tablet which a lot of company found cost effective compare to computers.

For home user this is not a problem as personal software isn't as expensive as enterprise software and are usually subscription/service based. Most user will never need to pay for a updated ARM version of the same app.
 
Back in the PPC->x86 transition, the practical performance gains were significant. Especially if you were coming from a G4 machine, using an x86 Mac just felt fast. Compute operations actually did complete sometimes 2x faster, and you felt it. Combining that with the fact that you now had native Windows support, and the fact that virtual machine products could use native emulation, it was a pretty easy sell to convince customers to move. Developers also liked being able to target and optimize for one architecture. There were some very clear advantages to getting on board with x86 that went far beyond just performance or power usage.

I'm having a hard time seeing similar gains for a move to ARM. With ARM, we give up native Windows support (sorry, Windows on ARM is still very beta in my experience). ARM chips may be more power efficient, but they don't necessarily perform faster, especially not faster in a way the average user will be able to feel day to day. Based on some benchmarks I've read, some of the best ARM CPUs are on par with the high end Core M series processors - and while those processors are decent, they're nowhere near even a Core i9 laptop part, let alone a Xeon processor as seen in the Mac Pro. The only place I see any benefit would be in laptops, where you might be able to advertise a Macbook that can last 12 hours in real world use on one charge. But this won't matter much for desktops, and pro users will demand the performance over the longevity.

The best outcome I see here is a mixed arch ecosystem. There's little reason today to force people onto one architecture. We've come a long way with compiler technology and automated builds and such, and if I recall, Apple already is doing some sort of bytecode-based compilation for the App Store, leaving the door open for a multi-arch runtime. Most other major programming languages are multi-arch (.NET, Python, etc.). I believe that Apple would be making a mistake if they try to move the entire ecosystem over to ARM. ARM has its place, and so does x86. x86 for pro, ARM for portables. And like I said, there's almost no reason not to do that these days. As Steve once said: "let each element be true to itself." If an ARM CPU wants to run at low power, let it serve the low power market. If an Intel chip wants to provide killer raw performance at the expense of higher power consumption, let it serve the pro market.

Then again, I'm sure Apple would love to be able to finally end the Hackintosh community. Ulterior motive?
 
  • Love
Reactions: Galve2000
I'm having a hard time seeing similar gains for a move to ARM.

I predict Apple's ARM will either run at 20% less power consumption for equal speed, or run 20% faster for the same power consumption/thermal envelope.

Maybe even better in terms of power consumption due to Apple controlling the whole software stack and having good experience having the OS send low-priority threads to "simple" cores (sort of like Big.Little, but better).

That's good enough for me.
[automerge]1582756784[/automerge]
Then again, I'm sure Apple would love to be able to finally end the Hackintosh community. Ulterior motive?

Right, because the 100 sales a year they lose to hackintosh keep them awake at night.
 
So that's simple:
Java stuff still runs. And actually good news for you: ARM CPU right now could runs Java much faster than Intel according to specjvm benchmarks.

Old commercial software have to be upgraded. But I guess everyone is moving to web based software regardless of Windows of Mac for quite some time now. That will be a good decision making information for the next time your company purchase new software as web software could runs on everything including phone and tablet which a lot of company found cost effective compare to computers.

For home user this is not a problem as personal software isn't as expensive as enterprise software and are usually subscription/service based. Most user will never need to pay for a updated ARM version of the same app.

What updated arm version are you talking about? Just because ms for example releases office for iPad doesn’t mean squat. It’s. Not. Office. It’s simply a lite toy version that isn’t usable in any way.

What dev is going to update Mac apps for an arm version? It’s hardly worthwhile to be a Mac dev now much less worry about a silly arm Mac that no one will buy because it’ll suck even worse than macs do now with Catalina.

Imo there is no arm Mac. There won’t be one. It’ll be an ipados iBook at the most. I can’t see Apple wasting their time screwing with macOS over A chips. It’s simply not worth it for them. Apple is all about iOS and turning it into adware for the clueless.
 
They already did this for Windows RT.
They have a bundled ARMv7 version of Win32 Office in it.
[automerge]1582676269[/automerge]


Technically it will only take a few weeks for developer to re compile your plugins into ARM.
Practically it will take about 2 years as that's how large software company's development cycle works.

You can keep using your old computer or rely on next Rosetta if it exist during this time.
And obviously if you rely on some died plugin with nobody maintain them then they will never be updated. Just like how everything was ported to Intel back in PowerPC time.

Someone with no DSP experience. PlugIns are typically written at a very low level often using optimized inline assembly.
Also the code is loaded into the cache and often the cache line locked so it won't be evicted. Porting DSP plugins from one processor to another is typically non-trivial which s why companies that make audio plug-ins hate platform changes.
[automerge]1582761849[/automerge]
Why does battery matter?

As for more cores, it depends on what you are doing. The OS, itself, is fairly light weight and, at its core, is essentially identical to iOS (BSD on Mach). In any event, a laptop/desktop version of an Axx chip will doubtless have more cores than the corresponding mobile versions.

We don't know a lot about the existing Axx architectures, but presumably they will:

1) increase the number of cores
2) add a lot of I/O
3) increase the sizes of each level of cache
4) potentially modify the cores to support a higher issue rate, perhaps by adding another pipeline (or, depending on what they are doing now, reduce contention by increasing the number of highest-functionality pipelines)
5) increase the size of TLBs, branch prediction RAMs, etc.
6) fiddle with the voltage controller

They probably do not need to resort to gimmicks like hyper threading.

If someone knows of any detailed discussion of what's in the latest Axx chips as far as microarchitecture, I'd love to read it.

Those companies building high performance ARM with custom designs aren't writing any papers.
Companies like Ampere aren't talking, just showing and shipping.
The Ampere eMAG is a 64-bit Arm V8.
It has 32 Arm v8 cores that trun at up to 3.3GHz; 32KB L1 I-cache and 32KB L1 D-cache per core, 256KB L2 per 2 cores and a global 32MB cache.

It supports up to 42 lanes of Gen3 PCIe.
ECC memory, etc.....
Built on TSMC 16nm FinFET+

Just remember, the Axxx or whatever it is, is going to get lots of power hungry IO.
Lots of pins and lots of power for PCIe differential I/O and multiple channels of LPDDR4/5.
Don't forget end to end ECC for that MacPro chip/s.
 
Last edited:
What updated arm version are you talking about? Just because ms for example releases office for iPad doesn’t mean squat. It’s. Not. Office. It’s simply a lite toy version that isn’t usable in any way.

What dev is going to update Mac apps for an arm version? It’s hardly worthwhile to be a Mac dev now much less worry about a silly arm Mac that no one will buy because it’ll suck even worse than macs do now with Catalina.

Imo there is no arm Mac. There won’t be one. It’ll be an ipados iBook at the most. I can’t see Apple wasting their time screwing with macOS over A chips. It’s simply not worth it for them. Apple is all about iOS and turning it into adware for the clueless.

As I told you before. You do not need to rewrite any code to make a x86 app run on ARM for the same OS.
Just like how iOS app runs on simulator on x86 CPU with 0 line of code change. That's part of iOS development.

You never seen any program code so it's really hard for you to understand and I know this. But believe me, porting the iPad version of office to a future ARM Mac is much harder than porting x86 macOS version to ARM Mac. Different OS is much more different than a different CPU architecture from a software developer prospective. And BTW Microsoft have already port win32 desktop Office suite to ARM before bundled with Windows RT.


If you still can not believe that, just copy a C program print "Hello world" in console and see how it runs on your Mac and your iPhone with no code changes needed.

And then try to build a window on macOS (x64) and a ViewController on iOS simulator(also x64). You gonna see huge difference in code even both of them are still running on Intel x64 CPUs.
 
Last edited:
It's new hardware to test for and maintain.
Fair point. Preparing the software for testing will be a low activity task. However, performance testing on a motherboard that may be significantly different from what developers may yield bugs NOT related to the CPU, but to the subsystems.
 
Someone with no DSP experience. PlugIns are typically written at a very low level often using optimized inline assembly.
Also the code is loaded into the cache and often the cache line locked so it won't be evicted. Porting DSP plugins from one processor to another is typically non-trivial which s why companies that make audio plug-ins hate platform changes.
[automerge]1582761849[/automerge]


Those companies building high performance ARM with custom designs aren't writing any papers.
Companies like Ampere aren't talking, just showing and shipping.
The Ampere eMAG is a 64-bit Arm V8.
It has 32 Arm v8 cores that trun at up to 3.3GHz; 32KB L1 I-cache and 32KB L1 D-cache per core, 256KB L2 per 2 cores and a global 32MB cache.

It supports up to 42 lanes of Gen3 PCIe.
ECC memory, etc.....
Built on TSMC 16nm FinFET+

Just remember, the Axxx or whatever it is, is going to get lots of power hungry IO.
Lots of pins and lots of power for PCIe differential I/O and multiple channels of LPDDR4/5.
Don't forget end to end ECC for that MacPro chip/s.

Mac dosn't have those DSPs. You do aware DSPs are hardware and not general purpose instructions right?
Plugins today are usually written in C/C++ and do not rely on any inline asm. They might be highly optimized/profiled for one CPU but are still portable.

Most audio plugins already get through the pain of moving from 32bit to 64bit. Those low level 20 years old code are long gone by now especially when system provide new low latency input/output and high performance compute libraries like Accelerate.
 
Back in the PPC->x86 transition, the practical performance gains were significant. Especially if you were coming from a G4 machine, using an x86 Mac just felt fast. Compute operations actually did complete sometimes 2x faster, and you felt it. Combining that with the fact that you now had native Windows support, and the fact that virtual machine products could use native emulation, it was a pretty easy sell to convince customers to move. Developers also liked being able to target and optimize for one architecture. There were some very clear advantages to getting on board with x86 that went far beyond just performance or power usage.

I'm having a hard time seeing similar gains for a move to ARM. With ARM, we give up native Windows support (sorry, Windows on ARM is still very beta in my experience). ARM chips may be more power efficient, but they don't necessarily perform faster, especially not faster in a way the average user will be able to feel day to day. Based on some benchmarks I've read, some of the best ARM CPUs are on par with the high end Core M series processors - and while those processors are decent, they're nowhere near even a Core i9 laptop part, let alone a Xeon processor as seen in the Mac Pro. The only place I see any benefit would be in laptops, where you might be able to advertise a Macbook that can last 12 hours in real world use on one charge. But this won't matter much for desktops, and pro users will demand the performance over the longevity.

The best outcome I see here is a mixed arch ecosystem. There's little reason today to force people onto one architecture. We've come a long way with compiler technology and automated builds and such, and if I recall, Apple already is doing some sort of bytecode-based compilation for the App Store, leaving the door open for a multi-arch runtime. Most other major programming languages are multi-arch (.NET, Python, etc.). I believe that Apple would be making a mistake if they try to move the entire ecosystem over to ARM. ARM has its place, and so does x86. x86 for pro, ARM for portables. And like I said, there's almost no reason not to do that these days. As Steve once said: "let each element be true to itself." If an ARM CPU wants to run at low power, let it serve the low power market. If an Intel chip wants to provide killer raw performance at the expense of higher power consumption, let it serve the pro market.

Then again, I'm sure Apple would love to be able to finally end the Hackintosh community. Ulterior motive?

Check Amazon Graviton2 32 cores ARM server processor.
On sepcjvm it's faster than current Xeon core by core!

And it is merely 105w TDP with all those ECC ram/PCIe connection and virtualization overhead.

If we trust anandtech's SPECint2006/SPECfp2006 data then A13 single core is reaching stock 9700k level performance. That's without any fan or other active cooling.

There's never a place for a CPU arch. ARM for mobile and x86 for Pro is the same joke as "x86 is for micro computer and will never become pro/server" 30 year ago.

x86 is not a advantage for performance. Instead, it is drawing back the performance for them. Intel already decide to move on and cut full x86 support from their next generation "rapids" arch.
 
Last edited:
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.