ahobbit said:

Xed said:

Apple has prepared for this for a long time—much longer than I would've preferred. Just like with the more recent moves from 32-bit to 64-bit or even the HIG for the iPhone aspect ratio and pixel density, if a developer isn't updating their code it's probably a good time to find better software.

Unlike with the transition from PPC to Intel, we probably won't have the same issues from MS and Adobe since they've been building wonderful apps for iOS and iPadOS for a  very long time. However, if they are lagging behind again due to taking shortcuts with their bloated codebase that makes it hard to transition then you either stick with your Intel Macs or switch apps. By the time you absolutely have to buy an ARM Mac these vendors will not be an issue.

That is easy for you to say, but the reality is much more complex.

What if companies like Autodesk will not port their Maya 3D code to ARM?

Sure, this might be a great example of "bloated codebase" for which you suggest moving to another app, or staying on Intel forever.

Staying on Intel Macs professionally is not a good idea, once that OS is no longer supported by Apple with security updates - at which point Autodesk most likely will also no longer offer latest Maya versions on mac OS.

Yet switching to another application is impossible if your clients dictate that you must use Maya 3D.

At that point I -must- abandon the Mac (or look for another job, I suppose...).

And that would not be by my choice but a choice that Apple forced on me.   

Not feeling good about that at all.

I speak as an iOS developer outside of my daily work, where my current role is doing developer support for another OS, but I have cross-platform development experience over many CPUs and OSes.

Short of them having a meaningful amount of hand-coded/optimized x86-64 CPU media-specific instructions, the transition for those applications should be trivial, assuming they're using the APIs for all the performance-critical things, which the OS provides for the reason that it's best to do that to be portable.  Short of that, it should be a simple recompile from x86-64 code to ARM64 code, because the endianness is identical, the size of pointers and whatever Apple will do within them is identical, so it won't have a functional problem.

Just for sanity, of course, it'd make sense to verify with a full test suite of the ARM64 MacOS version, just in case Apple did something amazingly stupid in the transition.  Again, I speak of this from having done several years of developer support for another OS for a living

So for the big productivity apps, if they don't port them quickly (where "port" should be a simple recompile with the exceptions mentioned above) then they're just being lazy.

rob53 said:

bobolicious said:

"Apple would also not be beholden to Intel" - is this ironic in that Apple now seems to make (almost) every move to increase customer dependence on a proprietary Apple ?

You do realize Apple is using ARM processor architecture with their own additional components. Apple isn't designing or building an entirely different CPU, it's still using the current ARM architecture so they are still at least partially beholden on ARM. The problem with Intel is they are slow as a snail in developing better and faster CPUs. ARM has been the faster developer of new CPUs not Intel so why should Apple continue to be slowed down by Intel? 

Apple is not a proprietary computer manufacturer. They have a few Apple-designed components but the vast majority of components are common. Read through an iFixit or other vendors teardown and you'll see all kinds of components without Apple's name on them. Even the bulk of macOS has been open-sourced, https://opensource.apple.com. ;

When it comes to ARM, Apple is an ARM ISA licensee: other than waiting on ARM to specify the layout of instructions and what they do, Apple has no constraints by ARM itself: they can achieve that ISA goal in any manner they want on their own timeframe, meaning Apple is then (at most) constrained from the outside by the foundry’s limitations and their own design ability.

The only way they could become less constrained by outside issues is to own a foundry for exclusive use.  If we reach a limit for process miniaturization then it might become worthwhile for them to own one if they don’t keep advancing technology, because foundries are very expensive and become outdated (currently) very quickly.

jdb8167 said:

ShapeshiftingFish said:

Would it be possible to make the current Mac Pro a dual processor architecture solution via a plug-in card? So to have a hardware acceleration instead of software emulation? It would be surprising if Apple didn’t think of a viable solution in order to not piss the pros (yet again), giving the short timeframe between releasing the new Pro and announcing the major architecture shift, which must have been in planning for a very long time. Yes, I know, Apple this and Apple that in not losing much sleep over radical transitions, but given the cost of the new Pro systems, this would be a huge slap in the face, even by their standards.

I suspect Apple has a two prong approach planned for the Mac Pro. First is a simple Intel Xeon CPU upgrade in the future as appropriate. The CPU is socketed in the current Mac Pro and the motherboard could easily be replaced. I don’t know the implications for things like PCIE 4.0 and above though.

But Apple must want to showcase their CPU design chops and what better place than the top of the line Mac Pro. If they can produce a 64 core Mac Pro that doubles the performance of the current 28 core Xeon, why wouldn’t they want to do that? We already know that there are companies producing 64 core ARM and above CPUs so it is certainly possible for Apple to do the same. For marketing reasons alone, making a new Mac Pro that destroys the current Intel Xeons would be a major win for Apple.

Making a CPU with 64 cores on it is one thing, but doing that while also providing enough memory bandwidth to be effective is another, without going to NUMA designs, where NUMA means Non Unified Memory Architecture: a number of CPU cores are grouped (theoretically down to 1) for each having shared access to main memory for those cores, and very limited sharing of memory between other groups of cores, because memory bandwidth can’t satisfy all the desired cores: they’re kept waiting on main memory most of the time, and have horrible cache coherency latency issues beyond a certain point.

Applications need to be architected in different ways than most are before NUMA is not a performance loss, or any given application can only use so many cores and be effective, while other applications use the other cores, with a minimal amount of sharing between them.

Most probable for heavy CPU threading scenarios is they’ll benefit with fewer faster cores far more; Amdahl’s Law defines the limits as to how linearly you can scale performance by adding more threads to a problem due to communication and synchronization overhead, and RAM throughout limitations combined with CPU cache coherency quickly make most processing tasks far less efficient: it’s even entirely possible and common that the more threads and cores you throw at a task, the slower it gets, to where you lose total throughout with a given larger number of cores than if you just used fewer cores of the same speed.

Consider in a more limited basis in smartphones: how much value was it for octocore Android devices? Not much! 

commentzilla said:

mjtomlin said:

I think people are missing something... Apple designs at most 2 SoCs a year, Ax, and AxX. For Apple to move the Mac line away from Intel they would have to design many more in order to differentiate performance between models. That's the thing they have with Intel right now; flexibility and versatility - options.

Is Apple simply going to put an A14 in all iMacs, Mac minis, and Mac Books? Where there is no performance options? Or will they be able to scale? A14I for mobile, A14IX for pro mobile, A14M for Mac, A14MX for pro Macs?

They would still be able to design a single new CPU every year, but would have to differentiate each SoC by the number of CPU cores and the clock frequency.

This is why I think they're designing their own ISA - something that can scale from efficient to performant and be highly optimized to run their code.

ARM is scalable and already highly optimized for iOS which is built on the same foundation as macOS. I think they'll need far fewer new chips than you think to get this off the ground. Based on the article below it looks like three total, which makes sense. One each for the laptops, desktops and the last for the MacPro. Clocking should provide enough scaling to differentiate performance between models. Then as the each new generation comes out they'll have the older CPUs to differentiate models further, just like they did this year with the 8th and 10th gen chips in the 13" MacBook Pros. They will also have the option to run CPUs in parallel in the MacPro just has they have in the past.

Whatever they do they are going to keep it streamlined and they certainly are not going to abandon ARM for anything else.

Apple will reportedly use 12-core 5nm ARM processor in a 2021 Mac

https://www.theverge.com/2020/4/23/21232441/apple-arm-mac-2020-5nm-processor-12-cores

Using history as a guide, as much as it seems quite probable Apple will transition the Mac line to ARM-derived ISA CPUs because they appear to be making performance improvements in both power and clock efficiency faster than Intel has, ARM ISA is just the latest CPU ISA for them to use on the Mac line.

There’s no guarantee Apple won’t ever discontinue the Mac line, as Apple has discontinued past computer lines before.  ARM-derived CPUs aren’t likely to be the last-and-greatest CPU ISA and most efficient ever designed: I’ve been following other CPU architectures, and there are some (At least one I know about) in development with promise of greatly exceeding power and instruction efficiency on the same process node (keep in mind Intel seems to be falling behind on process node, besides architectural efficiencies, compared to TSMC) compared to currently available CPU architectures.  That being said, until they’ve had a completed and tested-in-the-real-world chip made, they aren’t worth waiting for, something about counting your chickens before they hatch applies here  But, if they live up to their projections, I see no reason Apple wouldn’t transition to a completely new architecture if it results in a higher value than the price of keeping with the older CPU architectures, just like Apple has done twice before with Macs.

imat said:

Looking forward to ARM MacBook Pro. If it proves to be powerful enough it might be interesting. But not on the first iteration because, probably, software will have to be re-written to take full advantage of it. I still remember the "Rosetta" days and the Microsoft Office software running on Rosetta...

Recompiled? Yes.

Unless Apple changes behavior of APIs already used, or developers haven’t been properly using libraries for high-performance things that rely on CPU-specific instructions, no need or value in rewriting.

Previously Apple jumped from using Carbon to using what we have now: it’d be stupid for them to change again at the same time as a processor switch.