iOS 10, OS X 10.12, Apple A10 chip, and where this is all headed

[Toutou]

It is simply too costly to maintain a platform that generates much less profit but is based a completely separate CPU architecture.

The Mac doesn't only generate profit. More importantly it generates CONTENT. Without the Mac this whole glorious Apple ecosystem is ****ed beyond salvation.

Multi-core ARM chips (>12) means more energy efficiency and much longer battery life.

Also weird performance issues. Parallelism is hard. Most people don't seem to understand the relation between physical cpus (cores), threads and processes and how you can't just throw cores at any application and expect it to run better.

 

[lysingur]

The Mac doesn't only generate profit. More importantly it generates CONTENT. Without the Mac this whole glorious Apple ecosystem is ****ed beyond salvation.


Also weird performance issues. Parallelism is hard. Most people don't seem to understand the relation between physical cpus (cores), threads and processes and how you can't just throw cores at any application and expect it to run better.

Parallelism is hard but not that hard. It's not like it's a completely new technology or that we are not doing it right now. It's also not like Apple is abandoning the Macs or that Apple has never transitioned to a new CPU architecture before.

People always complain and blow things out of proportion. They did it when Apple moved away from PowerPC and they're doing it now when Apple decided to move away from x86.

 

[throAU]

Mac on ARM will not happen. The processing power isn't there and neither is the compatibility with existing software. It would be a huge amount of change and gnashing of teeth and loss of compatibility with other platforms for nothing. The current crop of intel CPUs are no slouch in processing power per watt, and outright faster than anything ARM has on the table. The Core Ms are pretty darn good at the low end, too.

Right now, the mac is popular with power users because it runs macOS, Windows, Linux and other platforms in virtual machines. Its the ultimate cross-platform developer/coder machine. Switch to ARM and that goes out the window immediately. If you want an ARM based machine, buy an iPad Pro and use that.

Wow. how times change. I'm 100% convinced that Apple will ditch intel within the next 5 years now due to the improvements in Apple CPU/GPU performance and the fact that intel have been stagnant.
[doublepost=1522916242][/doublepost]

Objective-C was being compiled to ARM ages before Swift made an appearance and while Swift might make cross-platform development somehow simpler, I am fairly sure that most Objective-C (or C++/C/etc.) code will compile to ARM without much of a problem. People don't do architacture-dependent code that much these days.

Obj-c used to run on 68k back in the NextStep days, so it isn't bound to x86 or x64 by any stretch.

That's a fair point, although I'm not sure that C++ code can be compiled to run on ARM (citation needed). Objective-C however, should work with ease.

C++ can run on ARM just fine. Like a raspberry pi. If i recall you can even do objective C++ in Xcode to target iOS (?).

High level languages are not processor specific. Thats the entire point of using them - you aren't tied to specific hardware. All you need is a compiler implementation.

 

[leman]

Obj-c used to run on 68k back in the NextStep days, so it isn't bound to x86 or x64 by any stretch.
...
C++ can run on ARM just fine. Like a raspberry pi. If i recall you can even do objective C++ in Xcode to target iOS (?).
...
High level languages are not processor specific. Thats the entire point of using them - you aren't tied to specific hardware. All you need is a compiler implementation.

The problem is not compiling in itself, but the assumptions that the code makes about the CPU architecture (endianness, pointer sizes, basic data structure alignment etc.). And as far as I know, they are identical between modern ARM and x86 CPUs. This is the crucial factor to allow true platform compatibility — if cross-compiled, your code should be able to work with data snapshots created by a different platform.

And already now you can create apps for iOS and macOS which share most (if not all) of their business logic. Even more, you can use same data structure declarations between CPUs and GPUs (this is what I really love about Metal for example).

 

[throAU]

The problem is not compiling in itself, but the assumptions that the code makes about the CPU architecture (endianness, pointer sizes, basic data structure alignment etc.). And as far as I know, they are identical between modern ARM and x86 CPUs. This is the crucial factor to allow true platform compatibility — if cross-compiled, your code should be able to work with data snapshots created by a different platform.

And already now you can create apps for iOS and macOS which share most (if not all) of their business logic. Even more, you can use same data structure declarations between CPUs and GPUs (this is what I really love about Metal for example).

Your obj-c code should not be making assumptions about endian-ness. it should be using the data types provided

If you have bit operations that are low level enough to do things that are endian dependent you should have put endian-ness ifdefs in there. If you didn't, now's the time...

It's not an insurmountable challenge. This is stuff people have done many times before with 68k, PPC, MIPS, Alpha, etc. Unless you're doing low level bit operations which is normally banging on hardware directly via assembler or low level C for driver code these days, you should just be able to recompile for the most part.


edit:
oh, you're talking about file storage using your own file types? yeah you might need to do checks there. But that's a file storage problem. Not a compilation or "will my code run" problem. But again, we've been there before. This might be a reminder to newer coders who haven't been through this stuff that you either make an assumption on endian-ness based on file format, or you embed and indicator of the endianness into the file somewhere.

 

[leman]

Your obj-c code should not be making assumptions about endian-ness. it should be using the data types provided

If you have bit operations that are low level enough to do things that are endian dependent you should have put endian-ness ifdefs in there. If you didn't, now's the time...

I never had any issues with cross-compiling my own code But sometimes people are a bit careless with their assumptions. Especially alignment and struct padding rules can be problematic. I always use armies of static_asserts to guard agains potential problems, but not everybody does.

 

[throAU]

Also, it would appear that 64 bit ARM is bi-endian.

 

[lysingur]

You've just got no idea. What you're suggesting is just not going to happen and has absolutely no precedent.

By the time that Apple released the first Intel iMac, they were claiming a 2-3x advantage in raw processing power over the G5 version. With the first Macbook pro, they were claiming 4-5x over the fastest G4 Powerbook.

These are the kinds of performance differences that motivated Apple last time and currently the fastest ARM out there is roughly equivalent to the lowest end of Intel CPUs. No one even knows if ARM will scale out to the speed of the Xeons whilst keeping their power consumption advantage, let alone scale out to multiples of Intel performance which would be required to make Apple switch.

Without ARM being multiples faster than Intel, you could also rule out any sort of Rosetta-like x86 emulation to run all the current apps during the years it would take to make the switch. They'd also have to forget about Bootcamp and running Windows and no more Windows or x86/Linux virtualisation.

Anyone who seriously thinks Apple would consider this switch to ARM in the near future doesn't understand the reasons for the switch the last time.
[doublepost=1466807871][/doublepost]

Rubbish. Absolute rubbish. The Windows to iOS+OS X ratio is 1.5:1 and even then it is totally disingenuous to include iPhones in this comparison.
[doublepost=1466808042][/doublepost]

What do you base this on? OS X and iOS have always had huge amounts of code in common.
[doublepost=1466808167][/doublepost]

HAHAHA. I love this. The "only" thing missing is the thing that is by far the most important, maybe not even possible and certainly not within your 3 year prediction.

Kuo: MacBooks With Apple-Designed Processors Coming Late 2020 or Early 2021, All-New Design to Follow in Mid 2021

In addition to forecasting the launch of new MacBook Pro and MacBook Air models with scissor keyboards in the second quarter of 2020, analyst...

www.macrumors.com