2016 nMP

[Mago]

I have Swift code that contains things that only run on ARM. It's not magic. Swift does not run in a virtual machine. It's not Java's compile once, run anywhere. It's the same as Obj-C, even sits on top of the Obj-C runtime..

I miss that, objective-c binaries don't run on top some runtime (as does visual basic), it link its executable binary to objective-c binaries or libraries as you like to name.

Exactly the same on swift once you compile some library for ARM your binary it's arm specific, once you compile the same library (as my Delaunay triangulation) for x86 you don't rewritten your library you only selected an different output from Swift compiler.

I suggest you to read on heterogeneous systems architecture, you desperately needs it's concepts.

A final comment, supporting an new architecture (cpu/gpu) while now it's easier than ever always has some cost, even if some app only need a simple re-compilation it needs new testing and distribution efforts which adds costs, most software vendors when on this, also use these events as justification for some improvements (and to bill it's customers), but isn't something as dramatic as to claim it's the world's ends.

Also we see it more often than you think, Intel is deploying AVX 2.0 by first on the Mac Pro, it's really improves vector related stuff by an order, you think implement AVX 2 will have no user costs? (involves most cases just a compiler switch) no way, you'll pay for it somehow.

 

[Bubba Satori]

I have no idea what you just said.

 

[Stacc]

I miss that, objective-c binaries don't run on top some runtime (as does visual basic), it link its executable binary to objective-c binaries or libraries as you like to name.

Exactly the same on swift once you compile some library for ARM your binary it's arm specific, once you compile the same library (as my Delaunay triangulation) for x86 you don't rewritten your library you only selected an different output from Swift compiler.

I suggest you to read on heterogeneous systems architecture, you desperately needs it's concepts.

A final comment, supporting an new architecture (cpu/gpu) while now it's easier than ever always has some cost, even if some app only need a simple re-compilation it needs new testing and distribution efforts which adds costs, most software vendors when on this, also use these events as justification for some improvements (and to bill it's customers), but isn't something as dramatic as to claim it's the world's ends.

Also we see it more often than you think, Intel is deploying AVX 2.0 by first on the Mac Pro, it's really improves vector related stuff by an order, you think implement AVX 2 will have no user costs? (involves most cases just a compiler switch) no way, you'll pay for it somehow.

Relax dude. Gomac is right. Every objective C and swift app are compiled for a specific architecture. That means they need to be recompiled for a new architecture. Sure, this may be an easy task with your swift code snippet, but its not an easy task for apps like Adobe Photoshop and Microsoft Office. When the mac transitioned from powerpc to x86, a reasonable temporary solution was to emulate powerpc on intel because intel's chips were so much faster so the performance penalty compared to native powerpc code was small. However, a modern transition away from intel today would carry no such speed benefit meaning that the transition would be very painful in the case of emulating apps that have not been migrated.

 

[Mago]

Relax dude. Gomac is right. Every objective C and swift app are compiled for a specific architecture. That means they need to be recompiled for a new architecture. Sure, this may be an easy task with your swift code snippet, but its not an easy task for apps like Adobe Photoshop and Microsoft Office. When the mac transitioned from powerpc to x86, a reasonable temporary solution was to emulate powerpc on intel because intel's chips were so much faster so the performance penalty compared to native powerpc code was small. However, a modern transition away from intel today would carry no such speed benefit meaning that the transition would be very painful in the case of emulating apps that have not been migrated.

Is not the same situation now as then, app migration have evolved a lot if you look into swift papers you'll notice that many provisions have been made to avoid the need for code "tune up" beyond a compiler switch.

 

[AidenShaw]

Also we see it more often than you think, Intel is deploying AVX 2.0 by first on the Mac Pro, it's really improves vector related stuff by an order, you think implement AVX 2 will have no user costs? (involves most cases just a compiler switch) no way, you'll pay for it somehow.

No Mac Pro supports AVX 2.0.

It was introduced in Apple laptops and the Imac about three years ago (late 2013 laptops, late 2013 Imac).

 

[Mago]

No Mac Pro supports AVX 2.0.

It was introduced in Apple laptops and the Imac about three years ago (late 2013 laptops, late 2013 Imac).

Will on June 13th will do...

 

[AidenShaw]

Is not the same situation now as then, app migration have evolved a lot if you look into swift papers you'll notice that many provisions have been made to avoid the need for code "tune up" beyond a compiler switch.

And who pays for recompiling with the new switch, and running the QA suites? Most vendors will choose to make such a change a "major version", and ask for more money.

Assuming that the vendor is still in business and still developing the product.

 

[Mago]

And who pays for recompiling with the new switch, and running the QA suites? Most vendors will choose to make such a change a "major version", and ask for more money.

Assuming that the vendor is still in business and still developing the product.

Previously stated point by point.

 

[AidenShaw]

Will on June 13th will do...

Doesn't change the fact that AVX 2.0 has been on other Apples for nearly three years, contrary to your claim.

And a "paper launch" on 13 June won't make it real. Apple may need to wait for Pascal GP104 production to ramp up before shipping.

 

[Stacc]

Is not the same situation now as then, app migration have evolved a lot if you look into swift papers you'll notice that many provisions have been made to avoid the need for code "tune up" beyond a compiler switch.

How many big apps are written in swift? Swift still has a long ways to go in both development of the language itself and major apps adopting it.

 

[Mago]

How many big apps are written in swift? Swift still has a long ways to go in both development of the language itself and major apps adopting it.

I remember you we talk on the hypothetic migration from Zen based Mac Pro to something like ARM, PowerX, also itanium, assuming typical Apple Mac Pro cycles we are taking about sometime 6 years from now, maybe at that time even binaries could be migrated to any processor even w/o source code.

 

[AidenShaw]

I remember you we talk on the hypothetic migration from Zen based Mac Pro to something like ARM, PowerX, also itanium, assuming typical Apple Mac Pro cycles we are taking about sometime 6 years from now, maybe at that time even binaries could be migrated to any processor even w/o source code.

AKA "Transitive"

http://www.cnet.com/news/the-brains-behind-apples-rosetta-transitive/#!

 

[Mago]

AKA "Transitive"

http://www.cnet.com/news/the-brains-behind-apples-rosetta-transitive/#!

Although this kind of "translator" could improve with enough support (money), actually I was thinking on SPIR-V as it seems will be adopted by Android to ditch VM and also allow new programing languages into the platform (supposedly is being considered an android compiler instead vm, this compiler will output SPIR-V or alike "binaries" you can run everywhere there is an Kernel with SPIR-V "translator" or whatever is named.

SPIR-V have it easy when compared with Java VM (or dalvik machine to avoid giving money to Oracle), but hardly could be the same when compared with real binaries out from GCC or others, but HSA is promoting this (beyond Google that actually needs it). At least for general applications not impacted by system performance it could success, or where the effort required to support heterogeneous architectures don't pay or can't wait.

 

[Zarniwoop]

As mentioned before, biggest reason to make a change from Intel to ARM would be the price. Apple could easily make couple of hundred more profit with ARM Macs. At least when using mobile processors. A9X is a lot faster than Macbooks Core-m series. And for Apple, it would be a lot cheaper to make.

My wild idea was some time ago, that Apple and AMD are working on ARM/Zen custom chip, which would be ARM native, but could run x86 compatible software on a window that is actually run on a Zen core, but user wouldn't notice the difference. It would just work. Two OS's' running on the same computer. HSA in the middle. That would be a transition period solution, until all software is x86 independent. After that period Apple could charge extra $$ from those needing x86 compatibility.

It has been speculated, that macOS could bring UIKit to desktop. One purpose would be to get rid of those dozens of browser "apps", I mean tabs - like Facebook, and make it work like an app. I am not sure, if iOS app would work directly with macOS, or it needs some tweaking, but these kind of apps are pretty much processor independent.

 

[Mago]

As mentioned before, biggest reason to make a change from Intel to ARM would be the price. Apple could easily make couple of hundred more profit with ARM Macs. At least when using mobile processors. A9X is a lot faster than Macbooks Core-m series. And for Apple, it would be a lot cheaper to make.

My wild idea was some time ago, that Apple and AMD are working on ARM/Zen custom chip, which would be ARM native, but could run x86 compatible software on a window that is actually run on a Zen core, but user wouldn't notice the difference. It would just work. Two OS's' running on the same computer. HSA in the middle. That would be a transition period processor, until all software is x86 independent.

It has been speculated, that macOS could bring UIKit to desktop. One purpose would be to get rid of those dozens of browser "apps", I mean tabs - like Facebook, and make it work like an app. I am not sure, if iOS app would work directly with macOS, or it needs some tweaking, but these kind of apps are pretty much processor independent.

No comments.

 

[wallysb01]

As mentioned before, biggest reason to make a change from Intel to ARM would be the price. Apple could easily make couple of hundred more profit with ARM Macs. At least when using mobile processors. A9X is a lot faster than Macbooks Core-m series. And for Apple, it would be a lot cheaper to make.

ARM processors themselves are cheaper than list prices of intel chips, sure. However, someone has to design those ARM processors. And if Apple is designing them, apple is taking on that cost. There really is no way to figure out how much A9X would cost if Apple sold it the way intel does with the core-M series. I'm hunch though: The A9X is a big, advanced chip and as such I don't think it would be all that cheap.

Also, as far as A9X being faster than core-m, you might want to do a little more digging. Things are bit more complicated than Geekbench scores: http://www.pcworld.com/article/3006...he-ipad-pro-really-isnt-as-fast-a-laptop.html

My wild idea was some time ago, that Apple and AMD are working on ARM/Zen custom chip, which would be ARM native, but could run x86 compatible software on a window that is actually run on a Zen core, but user wouldn't notice the difference. It would just work. Two OS's' running on the same computer. HSA in the middle. That would be a transition period solution, until all software is x86 independent. After that period Apple could charge extra $$ from those needing x86 compatibility.

It has been speculated, that macOS could bring UIKit to desktop. One purpose would be to get rid of those dozens of browser "apps", I mean tabs - like Facebook, and make it work like an app. I am not sure, if iOS app would work directly with macOS, or it needs some tweaking, but these kind of apps are pretty much processor independent.

That sounds like a lot of work to go sideways. I don't think Apple is gonna do that unless Intel really stops making perf/watt gains.

 

[Zarniwoop]

ARM processors themselves are cheaper than list prices of intel chips, sure.

It has been calculated, that to produce one A9 chip should costs between USD 22 to 37 for Apple. The more Apple makes those chips, the less is design cost per die. With ARM chip, Mac's could be as profitable as iPhone/iPad fleet. Tim Cook knows it.. he'd be out of his mind not to focus to benefit from that!

http://uk.businessinsider.com/analysis-iphone-6-plus-costs-prices-and-profits-2014-9?op=1?r=US&IR=T
[doublepost=1461429770][/doublepost]

Also, as far as A9X being faster than core-m, you might want to do a little more digging. Things are bit more complicated than Geekbench scores: http://www.pcworld.com/article/3006...he-ipad-pro-really-isnt-as-fast-a-laptop.html

Ok, let's say they're equally powerful. The price difference is still huge.

And what happens when you make A9 a quad-core version? Or overclock it some...?

 

[tomvos]

The switch from PowerPC to Intel on the desktop was a switch from a niche-architecture (at least for desktop and notebooks) to a mainstream architecture. Besides the well known performance advantages, this opened for Apple access to many good technologies and great people already working on BSD and Linux on the x86 platform. From my subjective point of view, many projects which had an average PowerPC OS X port changed into an excellent Intel OS X port that often was really on par with the other BSD and Linux ports.

My point is, switching to ARM on the desktop is switching from a mainstream architecture to a niche architecture (for the desktop). It might save some money for the CPU (however we have no exact figures). But nobody can tell how high the costs will be to bring the ARM OSX from the secret lab to full production level. And don't forget the costs of shipping all Apple software for both platforms for a few years.
Additionally ARM OS X would become more alien to many developers and the quality and availability of ports will most likely suffer.

I really fail to see any compelling argument why the Desktop needs ARM at the moment. The absolute performance and performance/watt is really ok with Intel's CPU. It's not that ARM is particularly bad, it just that they are not particularly better than Intel.

 

[Zarniwoop]

Good points. However, iOS is OS X running on ARM. I wouldn't be surprised, if Apple has had desktop OS X running on ARM for few years in their labs. Similarly like OS X ran on Intel since the beginning, but the first five years we didn't know about it.

It's just the rest of the software industry that will have to catch up. :-/

Anyway, ARM gives two things Apple loves most: full control, and full profit.

Who knows, maybe in future only Pro Macs run on Intel.

 

[tomvos]

Well, I guess it's an open secret that Apple keeps an ARM build of OS X. While not confirmed, I guess that nobody would be surprised if Apple one day says: "Oh, we had OS X running on ARM for years in our labs."
But running OS X in a lab is quite different to running the whole OS X platform and all Apple applications on ARM. For Apple it's cheap to pay two or three guys to build and maintain OS X for ARM just for fun. But once ARM is an official platform, it requires a lot more people to deliver the additional platform to the customer. That's quite expensive, not only because Apple needs to pay more people, but because Apple needs to find the people with the right qualification. And if I believe only half the rumors at the moment, I think Apple has other priorities than investing heavily into the desktop - neither into the Intel Desktop nor into the ARM Desktop.

Anyway, ARM gives two things Apple loves most: full control, and full profit.

So, what feature do you think Apple would add if they had full control over the Intel designs? I think Intel's current products offer good solutions to a very broad range of requirements.
On the contrary, once Apple has full control over anything, we most likely see proprietary stuff … so I really would prefer a market standard like x86 over Apple proprietary ARM stuff in all products.

 

[AidenShaw]

Well, I guess it's an open secret that Apple keeps an ARM build of OS X.

I bet that there's a POWER version running as well....

 

[Mago]

Well, I guess it's an open secret that Apple keeps an ARM build of OS X. While not confirmed, I guess that nobody would be surprised if Apple one day says: "Oh, we had OS X running on ARM for years in our labs."
But running OS X in a lab is quite different to running the whole OS X platform and all Apple applications on ARM. For Apple it's cheap to pay two or three guys to build and maintain OS X for ARM just for fun. But once ARM is an official platform, it requires a lot more people to deliver the additional platform to the customer. That's quite expensive, not only because Apple needs to pay more people, but because Apple needs to find the people with the right qualification. And if I believe only half the rumors at the moment, I think Apple has other priorities than investing heavily into the desktop - neither into the Intel Desktop nor into the ARM Desktop.



So, what feature do you think Apple would add if they had full control over the Intel designs? I think Intel's current products offer good solutions to a very broad range of requirements.
On the contrary, once Apple has full control over anything, we most likely see proprietary stuff … so I really would prefer a market standard like x86 over Apple proprietary ARM stuff in all products.

Maybe Apple wants to build an OSX server on ARM where it makes more sense, and actually Apple is going to rebuild it's own cloud services on its own controlled servers, server farm are moving to ARM due the big power savings, Amazon also purchased Annapurna Labs to build its own server cpu's both for internal hosts also to build appliances teaming with major Nas names as Synology.

A similar move from Apple wouldn't strange anybody.

 

[goMac]

I miss that, objective-c binaries don't run on top some runtime (as does visual basic), it link its executable binary to objective-c binaries or libraries as you like to name.

You should probably do some reading:
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ObjCRuntimeRef/index.html

Exactly the same on swift once you compile some library for ARM your binary it's arm specific, once you compile the same library (as my Delaunay triangulation) for x86 you don't rewritten your library you only selected an different output from Swift compiler.

That's entirely not true. Swift does nothing beyond what Obj-C already does to guard against multiplatform issues. If you're doing SSE or AVX optimizations, or working with data that is susceptible to endianness issues (both of which are very common situations for pro apps), you have just as big a problem. Apple does have some libraries that try to guard against those issues, like Accelerate, but if you're doing cross platform work you're not using Accelerate (like Adobe.) If you app is cross platform, you're also probably using C++, not Obj-C or Swift.

I believe Apple probably has a build of OS X for ARM. I'm really skeptical that it would ever be released unless something really went wrong with x86. And the slowing of Moore's law is not unique to x86.

 

[Mago]

You should probably do some reading:
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ObjCRuntimeRef/index.html
.

You link gives me the point:

the OS X Objective-C 2.0 runtime library support functions and data structures.

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 OS X implementation of the Objective-C runtime library is unique to the Mac. FOR [BOLD] other platforms, the GNU Compiler Collection provides a different implementation with a similar API[/BOLD] . This document covers only the OS X implementation.

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.

That's entirely not true. Swift does nothing beyond what Obj-C already does to guard against multiplatform issues. If you're doing SSE or AVX optimizations, or working with data that is susceptible to endianness issues (both of which are very common situations for pro apps), you have just as big a problem. Apple does have some libraries that try to guard against those issues, like Accelerate, but if you're doing cross platform work you're not using Accelerate (like Adobe.) If you app is cross platform, you're also probably using C++, not Obj-C or Swift.

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.

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.

 

[wallysb01]

It has been calculated, that to produce one A9 chip should costs between USD 22 to 37 for Apple. The more Apple makes those chips, the less is design cost per die. With ARM chip, Mac's could be as profitable as iPhone/iPad fleet. Tim Cook knows it.. he'd be out of his mind not to focus to benefit from that!

http://uk.businessinsider.com/analysis-iphone-6-plus-costs-prices-and-profits-2014-9?op=1?r=US&IR=T

That's just production/manufacturing costs, correct? I don't really know how anyone could know development costs. But just guessing, I'd imagine you could easily double the overall price if you include RD/QC type costs. Apple is also licensing the PowerVR GPU, how much does that run per chip? I have a hard time believing this is all included in $22-$37.

Ok, let's say they're equally powerful. The price difference is still huge.

But they aren't equal. Did you read that link I gave? Its maybe something around 1/2-2/3 the performance of core-m...

And what happens when you make A9 a quad-core version? Or overclock it some...?

It gets hotter and consumes more power and you might as well just use Intel chips? I don't really understand how anyone thinks ARM is some sort of magic bullet that will get around the same limitations Intel is hitting.