Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

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

nuckinfutz

nuckinfutz

macrumors 603
Jul 3, 2002
5,539
399
Middle Earth
KnightWRX said:
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 ?
Click to expand...

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
 
nuckinfutz

nuckinfutz

macrumors 603
Jul 3, 2002
5,539
399
Middle Earth
MacMilligan said:
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.
Click to expand...

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.
 
KnightWRX

KnightWRX

macrumors Pentium
Jan 28, 2009
15,046
4
Quebec, Canada
nuckinfutz said:
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.
Click to expand...

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.

nuckinfutz said:
Yes I'm aware of OpenGL ES versus OpenGL on the Mac and that's exactly where GLKit comes in.
Click to expand...

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.

nuckinfutz said:
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.
Click to expand...

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.

nuckinfutz said:
Not all of these frameworks existed in PPC days. AV Foundation. New. GLKit...new. Event Kit. New.
lots of new stuff
Click to expand...

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.

----------
nuckinfutz said:
For me I see the benefits as more autonomy for Apple.
Click to expand...

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.
 
N

Niff Stipples

macrumors newbie
May 4, 2011
13
0
KnightWRX said:
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.
Click to expand...

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

nuckinfutz

macrumors 603
Jul 3, 2002
5,539
399
Middle Earth
Eriden said:
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.
Click to expand...


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.
 
T

techwhiz

macrumors 65816
Feb 22, 2010
1,297
1,804
Northern Ca.
Apple Divorcing Intel??

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........
 
F

fxtech

macrumors 6502
Oct 13, 2008
417
0
dkersten said:
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.
Click to expand...

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

KnightWRX

macrumors Pentium
Jan 28, 2009
15,046
4
Quebec, Canada
Niff Stipples said:
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.
Click to expand...

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.

----------
nuckinfutz said:
]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.
Click to expand...

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.
 
nuckinfutz

nuckinfutz

macrumors 603
Jul 3, 2002
5,539
399
Middle Earth
KnightWRX said:
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.
Click to expand...

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

KnightWRX

macrumors Pentium
Jan 28, 2009
15,046
4
Quebec, Canada
nuckinfutz said:
The same PPC frameworks were used "if" they made the Carbon transition.
Click to expand...

Carbon was available on Intel...

nuckinfutz said:
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.
Click to expand...

You're again quite misunderstanding GLKit.

nuckinfutz said:
If you wish to get technical of course you can skip GLKit.
Click to expand...

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.

nuckinfutz said:
The benefit here is that Apple is making the frameworks portable across architectures.
Click to expand...

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

nuckinfutz said:
I'm not surprised you still need to OpenGL ES. GLKit just hit iOS in 6.0.
Click to expand...

iOS 5.0.

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

nuckinfutz

macrumors 603
Jul 3, 2002
5,539
399
Middle Earth
KnightWRX said:
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.
Click to expand...

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?

----------
KnightWRX said:
iOS 5.0.

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

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.
 
T

The Bulge

macrumors 6502
Oct 27, 2012
260
0
Up your ass.
nuckinfutz said:
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.
Click to expand...

I noticed that too.
 
P

pearvsapple

macrumors 6502
Feb 1, 2012
417
181
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.
 
Last edited:
H

hchung

macrumors 6502a
Oct 2, 2008
689
1
nuckinfutz said:
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.
Click to expand...

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

KnightWRX

macrumors Pentium
Jan 28, 2009
15,046
4
Quebec, Canada
nuckinfutz said:
I doubt that. While you have a modicum of technical ability you display cognitive issues, delivering extraneous information that is out of context.
Click to expand...

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*.
 
F

fajran

macrumors newbie
Aug 19, 2011
3
0
NL
nuckinfutz said:
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.
Click to expand...

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/beginning-opengl-es-2-0-with-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

xgman

macrumors 603
Aug 6, 2007
5,672
1,378
techwhiz said:
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.

.
Click to expand...


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

KnightWRX

macrumors Pentium
Jan 28, 2009
15,046
4
Quebec, Canada
bmac2021 said:
I will miss BootCamp!
Click to expand...

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.
 
V

Val-kyrie

macrumors 68020
Feb 13, 2005
2,107
1,419
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.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom