Apple's Potential Shift from Intel to ARM for Macs Not Implausible, But Faces Hurdles

[nuckinfutz]

Originally Posted by KnightWRX

How so ? Care to offer your insight as a software developer ?



You know when you're running that GL game on iOS, you're using OpenGL ES, either 1.1 or 2.0 and when you're running on OS X, you're using OpenGL, either a context based on the 2.1 specification or the new 3.2 context available since Lion.

You do know spatial sound support in OpenAL ? Not available on iOS, only "Stereo" mode.

And you realise that those frameworks existed in the PPC days and didn't change in the Intel transition right ? Right ?

You are a software developer to be commenting on this stuff ?

KnightWRX

Biggest difference that there were mobile PPC products back in the day. Even the Newton Messagepad used ARM chips then and not PPC so when Apple moved to Intel it was moving to an architecture that they had not field tested other than the Marklar builds.

Today I only need to show you my iPhone and iPad to show you field tested and mature applications and frameworks running on ARM. The potential transition to ARM would be so much easier because OS X on ARM isn't a skunkworks project.

Yes I'm aware of OpenGL ES versus OpenGL on the Mac and that's exactly where GLKit comes in. I don't know about you but in the brief time I've investigate OpenGL I smartly learned it was an area that I was interested in. That being said within the context of transitioning code, and please correct me if I'm wrong developers, but GLKit is an easier framework to write to and after writing against GLKit it will handle the lower level communication with the OpenGL stack.

Not all of these frameworks existed in PPC days. AV Foundation. New. GLKit...new. Event Kit. New.
lots of new stuff

[Monkeydude]

Originally Posted by chazmuzz

Windows 8 runs on ARM

No it does not. Only Windows RT runs on ARM- that's what a lot of Microsoft Surface buyers will realize when they want to install their 386 programs.

[nuckinfutz]

Originally Posted by MacMilligan

Ask yourself what the benefit is though. Sure ARM has lower tdp. A15 is around 1-2W (2-4 core), to get to 16 cores, we are talking 4-8W. New Haswell is set to hit 10W. Again, what's the point? A15 costs around $30-40, an A15 equivalent with 16 cores will cost more, possibly $70+. Haswell low-tdp will be likely stay the same price at around $80 for i5 and $120 for i7.

ARM will not touch i7 4-core speeds, which MacBook Pros use.

Then what happens with iMac and Mac Pro? Will they still support Intel in their desktops or are they going to also try to replace desktop i7's/Xeons with ARM? It is WAY too early to tell if ARM can be a real competitor in the desktop world. Unless you think Mac will split their laptop/desktop architecture, I just do not see this happening any time soon.

Then there is the problem with multithread scaling. You can not simply up the core count and the computer will run faster. At the end of the day IPC matters, just ask AMD. Again, ARM's fastest processors are only equivalent to Atom. There is no way this will happen anytime soon.

For me I see the benefits as more autonomy for Apple. Sticking with Intel means they follow Intel's release schedule and they cannot ad anything unique to the platform without Intel's consent. Why would Apple allow this to continue now that they are 5x larger than Intel (in Market Cap)?

I don't know anyone who's #1 that doesn't want to do it their way.

We're not talking about an A15 here. We're talking about ARM's new ARMv8 platform at the minimum which supports 64-bit and through a Corelink GIC-500 can link up multiple cores all sharing cache and managing affinity amongst the cores. This fight isn't about one on one. It's one (Intel) fighting a gang (multiple ARM cores)

To create a horrible analogy lets say you're fighting a midget. You likely have a size and strength advantage and will win easily. Let me toss in 5 more midgets. Things may get a little bit more difficult.

Speaking of IPC. Apple working on that with Macroscalar technology.

[linkgx1]

Originally Posted by Monkeydude

No it does not. Only Windows RT runs on ARM- that's what a lot of Microsoft Surface buyers will realize when they want to install their 386 programs.

*head explodes. Again*

[KnightWRX]

Originally Posted by nuckinfutz

KnightWRX

Biggest difference that there were mobile PPC products back in the day. Even the Newton Messagepad used ARM chips then and not PPC so when Apple moved to Intel it was moving to an architecture that they had not field tested other than the Marklar builds.

Today I only need to show you my iPhone and iPad to show you field tested and mature applications and frameworks running on ARM. The potential transition to ARM would be so much easier because OS X on ARM isn't a skunkworks project.

I think you missed the point by a mile. Framework availability was not an issue in 2005. Nothing has changed on that front, as you claimed. The same PPC frameworks were used on the Intel side. The same would be used on the ARM side.

There is no simplification of development that wasn't already there in 2005. Not the ones you've mentionned at least.

Originally Posted by nuckinfutz

Yes I'm aware of OpenGL ES versus OpenGL on the Mac and that's exactly where GLKit comes in.

GLKit does nothing to simplify those differences, unless you have very meager means as far as shaders go. GLKit simply sets up the view, provides texture loading from multiple image formats and provides some base shaders in the form of GLKBaseEffect and GLKSkyBoxEffect. Those shaders won't get you far unless you have some really simply requirements (like imitating OpenGL ES 1.1's fixed function pipeline in OpenGL ES 2.0).

GLKit does not hide the differences of OpenGL ES and OpenGL, because frankly that's not its goal.

Originally Posted by nuckinfutz

I don't know about you but in the brief time I've investigate OpenGL I smartly learned it was an area that I was interested in. That being said within the context of transitioning code, and please correct me if I'm wrong developers, but GLKit is an easier framework to write to and after writing against GLKit it will handle the lower level communication with the OpenGL stack.

You're wrong, that's not GLKit's goal. I use GLKit in my current project BTW, I spent a few months learning it. I still have to know OpenGL ES to get anything to work.

Originally Posted by nuckinfutz

Not all of these frameworks existed in PPC days. AV Foundation. New. GLKit...new. Event Kit. New.
lots of new stuff

New frameworks appear all the time, those frameworks don't help the transition because the transition issues are not related to framework availability.

It was related to making cross-compilation environnements, supporting both architectures, transitionning in-support applications by rebuilding them, passing them through regression and Q&A or just plain old Abandonware. The issue in the transition is not a developer issue really, most developers just choose the new target in Xcode and hit build.

The issue is one for users. Not every developer is willing to revisit older packages. Quicken 2007 ring a bell ? Office's PPC installer ? Freaking Adobe Creative Suite... some vendors will transition only new software, leaving users in the dust.

----------

Originally Posted by nuckinfutz

For me I see the benefits as more autonomy for Apple.

Benefits to Apple at the cost of benefits to users. You should really question on which side of that coin you want to be.

I don't care about benefits to Apple if it ends up hurting my own benefits. I'll move away to platforms that cater to their users rather than platforms that only profits the vendor.

[Niff Stipples]

Originally Posted by KnightWRX

Rosetta worked great because by the time Apple switched away to Intel processors, the x86 stuff was so ahead of the PPC stuff that the penalty for emulation didn't make it slow enough to notice.

A considerable and likely argument, when pondering future X86/ARM emulators -- there may simply be enough excess hardware horsepower available that the performance penalty for running some software under the control of an emulator becomes a non-issue, per se.


Niffy

[nuckinfutz]

Originally Posted by Eriden

Maybe for some, but not for everyone. If this transition pans out, it's obvious that Apple is more concerned with its consumer segment than it is with the installed base of professional users. Of course, the professional creatives have sensed this philosophical transition at Apple coming since the release of the originally gimped FCPX.

And even IF ARM and its partners are able to eventually create chips that match Intel's desktop class of processors in terms of performance, there are no guarantees that developers of professional applications will port their software to iOSX (or whatever they end up calling it).

If Apple really want to go down this road, they should just buy Adobe now and start rapid development of Creative Suite titles that will run well on upcoming performance-centric ARM chips.

Scalable processing can benefit creatives just as much as Big Data, Energy, Datacenters. Once developers moved to Carbon and then started to replace deprecated API with new 64-bit stuff they were already on the path of being able to move to ARM.

One of the reasons why Apple wanted to move off of GCC as a compiler technology was because LLVM delivers better analysis of your code. This allows Apple to develop better tools like DTrace and Instruments so developers can see where their code can be improved.

There's nothing to fear. If Apple moves to ARM...it'll be for performance reasons.

[techwhiz]

People just don't get it.
A newly released ARM 64 is in no way, shape or form. competition for an i7 with 4 cores and 8 threads. FOrget about it being anywhere near competition for a Xeon processor.

I'm so tired of analyst that know nothing about processor architecture thinking that just because it's 64 Bit is must be competition. Where is the full IEEE floating point extension to the ARM? What about a fast memory bus? What about multi-chip cache coherency?

Arm is just not the correct architecture for a desktop machine and you can ask other companies what it's like to try to compete in the processor performance arena when you don't own fabs.

Sheesh........

[fxtech]

Originally Posted by dkersten

Good thing Apple is looking out or its customers again. If there's one thing we need its a low power chip on all those desktops.

Yeah, they're looking out for their customers all right. Be prepared to buy all new hardware and then wait until developers get around to porting your favorite applications. Hope you don't mind re-buying some of them. Hopefully you don't use Bootcamp either, because that will go away too.

[KnightWRX]

Originally Posted by Niff Stipples

A considerable and likely argument, when pondering future X86/ARM emulators -- there may simply be enough excess hardware horsepower available that the performance penalty for running some software under the control of an emulator becomes a non-issue, per se.

That would require ARM designs to surpass Intel for performance in a very big way, which isn't likely considering the pace at which Intel is improving its offerings.

----------

Originally Posted by nuckinfutz

]One of the reasons why Apple wanted to move off of GCC as a compiler technology was because LLVM delivers better analysis of your code. This allows Apple to develop better tools like DTrace and Instruments so developers can see where their code can be improved.

LLVM has nothing to do with DTrace and Instruments. Apple also didn't develop DTrace, it's a Sun product, dates back to 2003 and shipped officially in Solaris 10.

Came to OS X in 10.5, waaaaaaaaaaaaaaaaay before LLVM.

[MH01]

Originally Posted by dkersten

Good thing Apple is looking out or its customers again. If there's one thing we need its a low power chip on all those desktops.

New Mac Pros are due next year

[Hell0W0rld]

Originally Posted by qtx43

It's a clever ploy by Tim Cook to keep Bob Mansfield happily working for Apple. There's nothing an engineer loves so much as a good challenge.

Not true...more money is better than challenges.

[nuckinfutz]

Originally Posted by KnightWRX

I think you missed the point by a mile. Framework availability was not an issue in 2005. Nothing has changed on that front, as you claimed. The same PPC frameworks were used on the Intel side. The same would be used on the ARM side.

There is no simplification of development that wasn't already there in 2005. Not the ones you've mentionned at least.



GLKit does nothing to simplify those differences, unless you have very meager means as far as shaders go. GLKit simply sets up the view, provides texture loading from multiple image formats and provides some base shaders in the form of GLKBaseEffect and GLKSkyBoxEffect. Those shaders won't get you far unless you have some really simply requirements (like imitating OpenGL ES 1.1's fixed function pipeline in OpenGL ES 2.0).

GLKit does not hide the differences of OpenGL ES and OpenGL, because frankly that's not its goal.



You're wrong, that's not GLKit's goal. I use GLKit in my current project BTW, I spent a few months learning it. I still have to know OpenGL ES to get anything to work.



New frameworks appear all the time, those frameworks don't help the transition because the transition issues are not related to framework availability.

It was related to making cross-compilation environnements, supporting both architectures, transitionning in-support applications by rebuilding them, passing them through regression and Q&A or just plain old Abandonware. The issue in the transition is not a developer issue really, most developers just choose the new target in Xcode and hit build.

The issue is one for users. Not every developer is willing to revisit older packages. Quicken 2007 ring a bell ? Office's PPC installer ? Freaking Adobe Creative Suite... some vendors will transition only new software, leaving users in the dust.

----------



Benefits to Apple at the cost of benefits to users. You should really question on which side of that coin you want to be.

I don't care about benefits to Apple if it ends up hurting my own benefits. I'll move away to platforms that cater to their users rather than platforms that only profits the vendor.

The same PPC frameworks were used "if" they made the Carbon transition.

GLKit as stated by developer.apple.com The GLKit framework provides functions and classes that reduce the effort required to create new shader-based apps or to port existing apps that rely on fixed-function vertex or fragment processing provided by earlier versions of OpenGL ES or OpenGL.

If you wish to get technical of course you can skip GLKit. The benefit here is that Apple is making the frameworks portable across architectures.

I'm not surprised you still need to OpenGL ES. GLKit just hit iOS in 6.0. It'll be a while before OpenGL mavens can lean on it heavily.

As for me and developers. If a developer doesn't support their app through transitions that's a stability and sustainability problem and I find a new app to support. I don't feel one bit sorry for Quicken users that got kicked in the teeth multiple times by Intuit and came back for more. You can track your finances with a spreadsheet just fine. It won't be glitzy but it'll work. Microsoft and Adobe have HUGE apps so I cut them a bit more slack.

I get your point Knight but even if we're talking about two years from now we've got yet another two major revisions of iOS and OS X.

[KnightWRX]

Originally Posted by nuckinfutz

The same PPC frameworks were used "if" they made the Carbon transition.

Carbon was available on Intel...

Originally Posted by nuckinfutz

GLKit as stated by developer.apple.com The GLKit framework provides functions and classes that reduce the effort required to create new shader-based apps or to port existing apps that rely on fixed-function vertex or fragment processing provided by earlier versions of OpenGL ES or OpenGL.

You're again quite misunderstanding GLKit.

Originally Posted by nuckinfutz

If you wish to get technical of course you can skip GLKit.

I never said anything of the sort. I said GLKit doesn't cover what you think it cover. It doesn't do what you think it does.

Originally Posted by nuckinfutz

The benefit here is that Apple is making the frameworks portable across architectures.

And that benefit was also there in the PPC days, a point you keep ignoring. (haven't I been clear enough ?)

Originally Posted by nuckinfutz

I'm not surprised you still need to OpenGL ES. GLKit just hit iOS in 6.0.

iOS 5.0.

Seriously, you're unarmed in this discussion. You don't have a grasp of the topic. At all.

[nuckinfutz]

Originally Posted by KnightWRX

LLVM has nothing to do with DTrace and Instruments. Apple also didn't develop DTrace, it's a Sun product, dates back to 2003 and shipped officially in Solaris 10.

Came to OS X in 10.5, waaaaaaaaaaaaaaaaay before LLVM.

I know. I didn't want to create a link between the Sun Open Source DTrace and LLVM but that may have inadvertently happened. Isn't there a tool now that can see where your app can be broken into threads in Xcode?

----------

Originally Posted by KnightWRX

iOS 5.0.

Seriously, you're unarmed in this discussion. You don't have a grasp of the topic. At all.

I doubt that. While you have a modicum of technical ability you display cognitive issues, delivering extraneous information that is out of context.

When I say "GLkit is available on Intel and ARM" I'm not asking for a treatise on shaders or OpenGL and OpenGL ES differences"

You attempt to overwhelm people with minutiae. I respect your "deep dive" technical knowledge to decline accepting your "unarmed" tag since I don't think you understand fully the scenario here.

[The Bulge]

Originally Posted by nuckinfutz

I doubt that. While you have a modicum of technical ability you display cognitive issues, delivering extraneous information that is out of context.

When I say "GLkit is available on Intel and ARM" I'm not asking for a treatise on shaders or OpenGL and OpenGL ES differences"

You attempt to overwhelm people with minutiae. I respect your "deep dive" technical knowledge to decline accepting your "unarmed" tag since I don't think you understand fully the scenario here.

I noticed that too.

[hchung]

Originally Posted by linkgx1

Hey what's the Watson CPU based on?

IBM's Watson?
Power7.
A monster of a chip design; an example of performance at all costs.

Yeah, that's "all" with bold, italics, and underline.

[pearvsapple]

Poor speculation. Intel's resources and progressiveness is unmatched. The future for x86 CPU is even higher performances and significantly lower power consumption to the point where Atom is no longer needed. They also manufacture their own toys, thus allowing Intel to manipulate the price of their products anyway it seem fit. ARM's future is lowend phones and $99 tablets. Won't be long until Job's dream of using Intel in iPad becomes a reality.

[hchung]

Originally Posted by nuckinfutz

You attempt to overwhelm people with minutiae. I respect your "deep dive" technical knowledge to decline accepting your "unarmed" tag since I don't think you understand fully the scenario here.

nuckinfutz, it pains me to watch this argument between you and KnightWRX. While on a high level, it sounds plausible. But by doing said "deep dive," it becomes obvious that whoever dreamed up this idea didn't do any of their homework. By ignoring the technical details, you don't seem to understand how unrealistic the scenario you're arguing for is, yet you continue to press for it.

KnightWRX (as well as MacMilligan, techwhiz, and other naysayers) are correct that switching Macs from Intel to ARM is a pretty bad idea for both Apple and for Apple's customers for the foreseeable future.

[KnightWRX]

Originally Posted by nuckinfutz

I doubt that. While you have a modicum of technical ability you display cognitive issues, delivering extraneous information that is out of context.

I'm trying to make you understand that GLKit does not help the Intel to ARM transition in a way it didn't the Intel to PPC transition.

High level frameworks do not change or help the difficulties associated with such transitions because high level frameworks have always been there. That's the point you keep missing and coming back with.

Get that out of your head right now.

The extra information I'm providing is so you can grasp that you misunderstand the purpose of those frameworks if you think they make a transition easier. They don't. They have nothing to do with transitions, as long as they are available on both sides, which they were for the Intel and PPC stuff...

GLKit is great. It really is. Fixed function pipeline is easier for starting in OpenGL ES, it helps people get up to speed in 2.0 really quickly without having to write shaders for basic stuff. But it does not help transition from Intel to ARM. Really. It doesn't.

*sigh*.

[bmac2021]

I will miss BootCamp!

[fajran]

Originally Posted by nuckinfutz

Yes I'm aware of OpenGL ES versus OpenGL on the Mac and that's exactly where GLKit comes in. I don't know about you but in the brief time I've investigate OpenGL I smartly learned it was an area that I was interested in. That being said within the context of transitioning code, and please correct me if I'm wrong developers, but GLKit is an easier framework to write to and after writing against GLKit it will handle the lower level communication with the OpenGL stack.

by "will handle lower level communication with the OpenGL stack" you mean GLKit is an abstraction layer?

Please open this GLKit introduction tutorial http://www.raywenderlich.com/5223/be...h-glkit-part-1 You still need to know how to code OpenGL, notice the gl* functions there. If GLKit is really an abstraction layer, you will never see those gl* function calls.

Compare it to, for example, OpenSceneGraph and OGRE. Those are more like to what you mean by an abstraction layer.

Also check again the GLKit documentation page. It mentions the features of GLKit but nothing about abstraction.

[xgman]

Originally Posted by techwhiz

People just don't get it.
A newly released ARM 64 is in no way, shape or form. competition for an i7 with 4 cores and 8 threads. FOrget about it being anywhere near competition for a Xeon processor.

.

We are years away from this parity and by then the Intel stuff will be miles from there. maybe Apple should just buy Intel and get it over with.

[KnightWRX]

Originally Posted by bmac2021

I will miss BootCamp!

Technically, ARM machines could multi-boot OSes, just like PPC could, just like SPARC, Alpha, Mips, PA-RISC, etc.. all could.

Bootcamp would work fine on an ARM Mac. It would resize your disk, configure your boot loader, and help you on your way to installing... some other ARM based OS.

[Val-kyrie]

This news is not surprising, especially in light of Microsoft's interest in the ARM architecture. I highly doubt we will see OS X on ARM chips for Apple's notebooks and desktops unless and until MS also decides to move in that direction for its OS. Both companies seem to be tracking in the same general direction, including a focus on tablets. I suspect any transition to ARM is 3-5 years away yet.