You see, if Apple can create 100-500 million extra profit by sacking Intel from low power computers, they'll have no pity for x86. Money is the god they trust. Follow the money... Apple is no different.
The cost for materials for ARM is much lower, but the spinup cost is much higher. Spinning up factories, making production lines to produce the chips... That's going to be very expensive, especially if Apple is trying to move production in house. It's not like they have a warehouse full of spare chips here.
It's probably a mistake to compare the materials cost of an ARM processor to an Intel processor. Once you've scaled up the design and set up manufacturing, the cost is probably more expensive. Not to mention, Intel has a lot of expertise in producing laptop and desktop scale chips that Apple doesn't. Apple doesn't even have that expertise in house yet for their iOS devices.
And if Apple wades into the ARM computer arena... ARM computers are cheap. Yes, they could generate extra profit in theory... But competing head to head with ARM devices would mean price drops.
I also just flat out don't see how an ARM chip would work well in the Mac Pro right now. There just isn't anything competitive with a 12 or 20 core Xeon in the ARM camp right now. It's kind of a silly notion.
[doublepost=1461451623][/doublepost]
This means, the code you compile it's linked with said library, very different to say that objective-c code runs on top of such runtime library, objective-c does the same thing as MS VC++ which link you code with the windows/vc++ MFC an spiritual doppelganger of the Objective-C runtime
"The document is intended for readers who might be interested in learning about the Objective-C runtime."
I don't really need to argue the point past that.
That means you don't need to care on the Objective-C runtime if you switch to Linux (a.e.) because the GNU Compiler will provide a custom implementation of the Objective-C runtime but KEEPING the API, that means you don't need to change a single line of code to interact with the library (for the purposes the library is provided only, don't include other os<->obj-c)
So you helped me to demonstrate my point, source code portability is not a problem of cpu platform.
You're mixing together operating systems and CPUs like the same thing. Talking about portability to Linux is not that same thing as talking about portability between CPUs. But regardless, the document itself even says portability to Linux is not guaranteed, so even then...
First I remember you the thread is related to migrate OSX from /x86 to something different as ARM, code portability among different OS It's another issue.
...Right?
Doing SSE AVX and other cpu optimizations it's matter of compiler switches and in few cases some "in-line" code which often it's c/c++/asm, and such in-line or pragmas well coded should be invisible as you link to other cpu platform.
https://developer.apple.com/library...nCL_MacProgGuide/Performance/Performance.html
Please take your time reading this, worth for you to educate on programming issues beyond "fast" reading or just Google on concepts you are no familiar with.
Why are you giving me an OpenCL document in response to SSE or AVX?
Even if you have in line switches, someone has to write the code for ARM that goes inside the ARM switch. There's no compiler flag that translates SSE or AVX to NEON, just as there was no magic compiler flag that translated Altivec into SSE. Like I said, this all happened before in 2005, and nothing has really changed since.