But Apple made that transition for its entire range of desktop and notebook computers.
It would not make sense for just one line of notebooks?
C.
Put an ARM emulator in XCode, and make it create fat binaries (x86 and ARM) by default. In fact, Apple can start doing it now, even with no ARM Mac. Yet
ARM architecturally is no less than x86, it is just that the focus of ARM is mobile, the MacBook Air is the ultimate mobile Mac. In fact if an ARM CPU were used, it can perform better and get better battery life. We now have 1GHz ARM CPUs in smartphones and this is without overheating and with acceptable battery life. The MacBook Air has the thermal envelope to handle a 2GHz ARM or even more.
Quote:
Originally Posted by wizard69
They also don't seem to understand what architecture is and the vast difference between ARM and Intel. It is more than just the 32 bit or 64 bit question, the differences are vast. Further ARM can not effectively emulate an intel processor. Each time in the past when Apple has switched architectures they have done so when the new architecture was significantly faster so that emulation was viable.
I more than understand how ARM and x86 are different. PPC and x86 were vastly different, even in endianess. Before bringing a MacBook Air using an ARM CPU, Apple needs to make sure the fat binaries are out there.
The gap between ARM and x86 in performance is diminishing fast. ARM is eying the desktop market, the smartbook and netbook markets are but stepping stones.
Quote:
Originally Posted by Ireland
When I say I would like a reason, I mean the reason why you want an ARM chip in a Mac?
Better battery life, less heat dissipation which means the CPU can be run at a higher clock rate, and even allow for a slimmer and lighter design.
Put an ARM emulator in XCode, and make it create fat binaries (x86 and ARM) by default. In fact, Apple can start doing it now, even with no ARM Mac. Yet
ARM architecturally is no less than x86, it is just that the focus of ARM is mobile, the MacBook Air is the ultimate mobile Mac. In fact if an ARM CPU were used, it can perform better and get better battery life. We now have 1GHz ARM CPUs in smartphones and this is without overheating and with acceptable battery life. The MacBook Air has the thermal envelope to handle a 2GHz ARM or even more.
I more than understand how ARM and x86 are different. PPC and x86 were vastly different, even in endianess. Before bringing a MacBook Air using an ARM CPU, Apple needs to make sure the fat binaries are out there.
The gap between ARM and x86 in performance is diminishing fast. ARM is eying the desktop market, the smartbook and netbook markets are but stepping stones.
Better battery life, less heat dissipation which means the CPU can be run at a higher clock rate, and even allow for a slimmer and lighter design.
It sounds like you believe ARM-based processors can eventually match the performance of Intel's x86-based processors while at the same time have lower heat dissipation and longer battery life. How do you propose ARM achieve this magic? I dislike the CISC to RISC code decoding overhead of modern x86 processors and wish x86 would go away as much as the next person, but we have no choice but to acknowledge that despite this legacy CISC overhead, Intel's x86 chips are highly optimized and efficient processors capable of beating out the best of the RISC world such as UltraSPARC and POWER. So I don't see how ARM-based designs can match x86 performance while achieving better efficiency. Current ARM-based chips are so efficient because they are just much simpler and less powerful than most x86 chips. They are just missing so much stuff compared to x86 processors, like deep pipelining, superscalar execution, out-of-order execution, branch prediction, macro-op fusion, barrel multithreading, that at the same clock speed they consume much less power than x86 processors because they are just much smaller cores. Sure, recent ARM designs have been adding stuff, Cortex A8 got a deep pipeline and superscalar execution, Cortex A9 added out-of-order execution and branch prediction. But the question is, once ARM-based cores get all this stuff that they are able to match x86 performance, will they be any more efficient?
It sounds like you believe ARM-based processors can eventually match the performance of Intel's x86-based processors while at the same time have lower heat dissipation and longer battery life. How do you propose ARM achieve this magic? I dislike the CISC to RISC code decoding overhead of modern x86 processors and wish x86 would go away as much as the next person, but we have no choice but to acknowledge that despite this legacy CISC overhead, Intel's x86 chips are highly optimized and efficient processors capable of beating out the best of the RISC world such as UltraSPARC and POWER. So I don't see how ARM-based designs can match x86 performance while achieving better efficiency. Current ARM-based chips are so efficient because they are just much simpler and less powerful than most x86 chips. They are just missing so much stuff compared to x86 processors, like deep pipelining, superscalar execution, out-of-order execution, branch prediction, macro-op fusion, barrel multithreading, that at the same clock speed they consume much less power than x86 processors because they are just much smaller cores. Sure, recent ARM designs have been adding stuff, Cortex A8 got a deep pipeline and superscalar execution, Cortex A9 added out-of-order execution and branch prediction. But the question is, once ARM-based cores get all this stuff that they are able to match x86 performance, will they be any more efficient?
And to answer your question, a resounding yes! Because it wont have decoding circuitry for complex instructions to simpler ones.
The only reason x86 can compete with POWER and UltraSPARC is due to Intel's sheer mount of resources it thrown into it. That and Sun didn't push UltraSPARC hard enough. Look at what Fujitsu managed to do with SPARC64. Going back to POWER, I don't think x86 compete, not on the server and supercomputer level. Just take a look at POWER7. IBM and Freescale did ignore PowerPC on the desktop, Apple was but a drop in the bucket for them and didn't warrant the investment needed to push PowerPC forward. But look what IBM managed to do with PowerPC for Microsoft. Unlike Apple, Microsoft was involved in the design and payed IBM a nice sum of cash.
Oh and why do you think Intel came up with Itanium and tried to push it hard? Intel wanted to transition to IA64, but killing x86 is something no one can do, not even Intel.
And to answer your question, a resounding yes! Because it wont have decoding circuitry for complex instructions to simpler ones.
The only reason x86 can compete with POWER and UltraSPARC is due to Intel's sheer mount of resources it thrown into it. That and Sun didn't push UltraSPARC hard enough. Look at what Fujitsu managed to do with SPARC64. Going back to POWER, I don't think x86 compete, not on the server and supercomputer level. Just take a look at POWER7. IBM and Freescale did ignore PowerPC on the desktop, Apple was but a drop in the bucket for them and didn't warrant the investment needed to push PowerPC forward. But look what IBM managed to do with PowerPC for Microsoft. Unlike Apple, Microsoft was involved in the design and payed IBM a nice sum of cash.
Oh and why do you think Intel came up with Itanium and tried to push it hard? Intel wanted to transition to IA64, but killing x86 is something no one can do, not even Intel.
So perhaps ARM will turn out to be the x86 killer? Haha, that would be nice. It does have the advantage of not incurring the x86 decoding overhead, but there's still an enormous hurdle to climb: the billions Intel pours hand designing its chips and building foundries with the best fab processes. Time and time again we see superior architectures falter against this might, it's almost like a tragic tale. I always thought Sun would be the one to finally do x86 in (the MAJC sounds like such a great idea!) but it looks like all those chip designers they have were goofing off half the time, and now that hope is no longer possible. It would be interesting, to say the least, if an ARM-based design turns out to achieve the impossible.
Put an ARM emulator in XCode, and make it create fat binaries (x86 and ARM) by default. In fact, Apple can start doing it now, even with no ARM Mac. Yet
Apple already does have an Arm emulator in XCode. But again I question the wisdom of making a processor shift for just one line of product, which is (by all accounts) not Apple's best selling notebook.
Apple makes two main lines.
Media centric portable appliances. iPhone, iPad, iPod.
Productivity focussed computers. Macs (desktops and notebooks)
There's a simple strategy here with processors. The portable media devices run ARM while the computers run Intel.
So while I agree that an Arm-powered Macbook Air is possible. I think the costs of porting not just Mac OS, but all drivers and all third party applications just for one notebook line is not justifiable.
And to answer your question, a resounding yes! Because it wont have decoding circuitry for complex instructions to simpler ones.
The only reason x86 can compete with POWER and UltraSPARC is due to Intel's sheer mount of resources it thrown into it. That and Sun didn't push UltraSPARC hard enough. Look at what Fujitsu managed to do with SPARC64. Going back to POWER, I don't think x86 compete, not on the server and supercomputer level
On the supercomputer level x86 certainly competes. It's cheap, easily available, most scientific software is developed heavily on it...
While I've run jobs on Blue Gene systems, the majority of the clusters I run on, and the majority of "supercomputer" class clusters out there in general are x86 based.
Take a gander at the top500 if you dont believe me. Also, while I'm not sure if its up on the site, at the top500 presentation at supercomputing they usually go through a very interesting set of breakdown numbers and graphs to go along with them comparing current architecture to historical trends - if it's up should be good reading if you're interesting in exploring the numbers further.
On topic though:
No way the Air switches to ARM, it would lose too much compatibility with mainstream osx software. Also, the air is competing in the relatively high-end, work-usable sub-notebook category, not the netbook/media category the iPad seems to be aimed at, no reason they cant co-exist.
On the supercomputer level x86 certainly competes. It's cheap, easily available, most scientific software is developed heavily on it...
While I've run jobs on Blue Gene systems, the majority of the clusters I run on, and the majority of "supercomputer" class clusters out there in general are x86 based.
Take a gander at the top500 if you dont believe me. Also, while I'm not sure if its up on the site, at the top500 presentation at supercomputing they usually go through a very interesting set of breakdown numbers and graphs to go along with them comparing current architecture to historical trends - if it's up should be good reading if you're interesting in exploring the numbers further.
On topic though:
No way the Air switches to ARM, it would lose too much compatibility with mainstream osx software. Also, the air is competing in the relatively high-end, work-usable sub-notebook category, not the netbook/media category the iPad seems to be aimed at, no reason they cant co-exist.
The processor used in cluster nodes is interesting, but is hardly indicative of much in and of itself. For one thing, the power of a cluster is determined by the number of nodes in the cluster. Need more power? Add more nodes. This is one of the consequences of the fact that x86-based nodes are cheap, a fact that you got absolutely correct.
Aizmov is also absolutely correct. IBM had turned its attention away from personal computing to concentrate on workstations and servers. A PPC G3 did not generate enough heat to incubate an egg. IBM had a distinct advantage over Intel. However, the G5 generated enough heat to fry an egg. OTOH, Intel had developed new fab techniques that substantially reduced heat generation in its processors. A G4-based laptop would scorch your clothing. A G5-based laptop was impossible. However, IBM did not care. At least, not until Apple announced that it would switch to Intel.
In terms of shear computing power, the POWER/PowerPC architecture was plenty powerful. It bears remembering that at the time IBM was still selling low-priced workstations based on the PPC 604, the same processor used in the Power Macintosh 9500. The G5 smoked the PPC 604. Without question, Intel-based Macs are more powerful than comparable PPC-based Macs of yore. However, the performance advantage is largely determined by the processor clock speed and the number of cores.
What is this all getting to? The POWER7 seems to indicate that IBM has finally seen the light. At 4.1 GHz, its clock speed is faster than anything that Intel has on the market. It also eight cores per processor. It also appears to generate substantially less heat than the old POWER processor modules. In terms of hardware capability, IBM appears to have a big winner.
Now for the issue of software. For scientific computing, you are just plain wrong. Computational science programs are written in FORTRAN or C/C++. These programs are compiled on the target computer using standard open source or commercial compilers. Optimization is done within the compiler. Unlike commercial apps, computational science programs are rarely optimized by hand to maximize performance.
ARM chips are designed for somewhat different purposes than most x86 chips are. Yes, the ARM core is vastly more efficient than the x86 core is: this is because every core is more efficient than the x86. But for a large memory system, most of the CPU is actually just cache memory. ARM chips do not generally have as much memory, they have more simplistic caching systems, and more simplistic FPUs.
That said, they can still be extremely effective in more controlled environments where you can prevent chaos in the cache. The iPhone is a good example: it runs one user process at a time.
If you were to beef-up an ARM with a sophisticated, large cache and a powerful, vector FPU, then it wouldn't be that much more efficient than a comparable x86.
The processor used in cluster nodes is interesting, but is hardly indicative of much in and of itself. For one thing, the power of a cluster is determined by the number of nodes in the cluster. Need more power? Add more nodes. This is one of the consequences of the fact that x86-based nodes are cheap, a fact that you got absolutely correct.
Aizmov is also absolutely correct. IBM had turned its attention away from personal computing to concentrate on workstations and servers. A PPC G3 did not generate enough heat to incubate an egg. IBM had a distinct advantage over Intel. However, the G5 generated enough heat to fry an egg. OTOH, Intel had developed new fab techniques that substantially reduced heat generation in its processors. A G4-based laptop would scorch your clothing. A G5-based laptop was impossible. However, IBM did not care. At least, not until Apple announced that it would switch to Intel.
In terms of shear computing power, the POWER/PowerPC architecture was plenty powerful. It bears remembering that at the time IBM was still selling low-priced workstations based on the PPC 604, the same processor used in the Power Macintosh 9500. The G5 smoked the PPC 604. Without question, Intel-based Macs are more powerful than comparable PPC-based Macs of yore. However, the performance advantage is largely determined by the processor clock speed and the number of cores.
What is this all getting to? The POWER7 seems to indicate that IBM has finally seen the light. At 4.1 GHz, its clock speed is faster than anything that Intel has on the market. It also eight cores per processor. It also appears to generate substantially less heat than the old POWER processor modules. In terms of hardware capability, IBM appears to have a big winner.
Now for the issue of software. For scientific computing, you are just plain wrong. Computational science programs are written in FORTRAN or C/C++. These programs are compiled on the target computer using standard open source or commercial compilers. Optimization is done within the compiler. Unlike commercial apps, computational science programs are rarely optimized by hand to maximize performance.
Perhaps poorly phrased by me on the "scientific software" comment, what I meant by
Quote:
On the supercomputer level x86 certainly competes. It's cheap, easily available, most scientific software is developed heavily on it.
is that most scientific software [used on supercomputers] is heavily developed on x86 clusters because of the availability, not that it wont run on other arches. I was talking about the heavy usage of x86 in scientific/supercomputing work, not the limitations of the software. (Disclaimer here: I both work on several clusters, and heavily use for research several different highly scalable, cluster-targeted, modeling tools.)
I dont disagree with you on the advances in other arches. POWER/PowerPC are far nicer than x86 as an arch, and I'm rather fond of sparc machines. The most powerful machine I currently can and do run jobs on is NY Blue (http://www.bnl.gov/newyorkblue/), which is most definitely not x86!
If you look at what I was replying to I was simply refuting Aizmov's claim:
Quote:
I don't think x86 compete, not on the server and supercomputer level
You seem to say that because licensing out chip designs works for ARM, Intel would have no problem doing it.
No the point is if they want to compete with ARM they need to be able to work with customers to offer up custom solutions. They don't have to actually license out the core. What they do need is a different model than the one where every customer gets what Intel designed and though was needed on a SoC. What is notable about ATOM is that it is pathetic with respect to integration especially compared to what the ARM world offers up.
Quote:
What you are ignoring is that Intel operates with an entirely different business model.
Nope, what I'm saying is that their business model needs to change to compete with ARM based devices.
Quote:
They don't license out their chip related designs to just anyone, and they are not a foundry. As far as I know they've never manufactured anyone else's chips with their fabs. And just look at the history of Intel's licensing terms with their CPU-related designs. The x86 licensing terms with AMD went through several court battles, and Intel has threatened to withdraw its cross-licensing deal with AMD should AMD split up into a chip designer and a foundry.
Well a time will come when the ability to force licenses of x86 will be gone.
Quote:
And Intel has refused to license DMI, another technology that's important for their chip designs, to nvidia. There have been no indications that Intel will dramatically change their business model and start licensing out their designs or start becoming a foundry for other chip designers, so it's only rational to expect the status quo to continue. It's far more likely that Intel will attempt to make their own SoC design than work out some kind of deal that they've never done before with someone else.
Well Intel is way to late to the SoC party. As to their attempt to manipulate the market by restricting licensing I have a funny feeling that their ability to do that will be very limited in the future as the government takes notice.
No the point is if they want to compete with ARM they need to be able to work with customers to offer up custom solutions. They don't have to actually license out the core. What they do need is a different model than the one where every customer gets what Intel designed and though was needed on a SoC. What is notable about ATOM is that it is pathetic with respect to integration especially compared to what the ARM world offers up.
Nope, what I'm saying is that their business model needs to change to compete with ARM based devices.
Well a time will come when the ability to force licenses of x86 will be gone.
Well Intel is way to late to the SoC party. As to their attempt to manipulate the market by restricting licensing I have a funny feeling that their ability to do that will be very limited in the future as the government takes notice.
Dave
Oh I see what you are saying. Perhaps Intel would need to adopt the ARM model to have success in the SoC market. But I could see Intel just going the "this is our SoC and you will use it and you will like it" route.
That would be pretty weird. Intel would have to license x86 and QPI/DMI to Apple for PA Semi to design the SoC chip package, and Apple would then license it back to Intel for Intel to make it (I don't see Intel opening up its fabs to make chips for someone else, so Apple would have to license the SoC to Intel). Or Apple and Intel could make a cross-licensing deal, but that may have other PC manufacturers up in arms
Why would intel have to license anything from Apple? It would be a custom order.
Quote:
And it's unlikely Intel will do cross-licensing with an ARM licensee, since Intel has their rival Atom platform.
If they did business like that they would have any customers. Hell, they do business with AMD. Why? Because there is money to be made.
Oh I see what you are saying. Perhaps Intel would need to adopt the ARM model to have success in the SoC market. But I could see Intel just going the "this is our SoC and you will use it and you will like it" route.
But I don't see them being successful. Besides that ARM is being very aggressive going after the latest process technologies thus enabling even higher integration, lower power and faster performance. Last I heard ARM is already working towards Cortex on a 28nm process. That may be a way off but what it says is that Intel doesn't have a process technology advantage anymore. If anything ARMs smaller cores effectively give them advantages a process step or two behind Intel.
The important thing to take out of the process discussion is that the shrinking processes and ARMs smaller cores mean that SoC built with the tech can economically have higher integration and more features. Sure the performance is nice, but it is cost that make ARM so attractive. Just try to imagine fitting a ATOM into an iPhone in an economic manner.
ARM will never catch up to Intel x86 for laptops and desktops CPUs or whatever integrated unit they'll have in the future. No one will. That's pretty much the end of the story.
The economics simply aren't feasible anymore. It basically ended when DEC and AIM couldn't convince MS to port Office to NT/Alpha and NT/PPC in the 90s.
I do believe the iPad-ization of computing is possible where the majority of computing devices are ARM devices like handheld and slate form factors, but for your traditional laptop and desktop space, Intel has basically won, and will be in those systems until something other than CMOS-based chips takes over.
To reiterate, a MBA with a Core i3 will absolutely destroy any ARM machine in any performance metric by a factor of 4 or more. The only metric ARM can be competitive in is standby time and battery burn down time. Now, if all you want your MBA to do is iPad like tasks, an ARM-based MBA could be interesting, but Apple won't be selling any of those for $1500. And hence, Apple won't even be offering such a system.
The economics simply aren't feasible anymore. It basically ended when DEC and AIM couldn't convince MS to port Office to NT/Alpha and NT/PPC in the 90s.
....
Who told you that? The issue in the 1990s was not Office. The dominant word processor was Corel WordPerfect. The dominant spreadsheet was Lotus 1-2-3. Lack of Micrsoft Office was not a dealbreaker. That said, non-Intel versions of NT included an embedded version of SoftWindows to emulate Intel processors. Therefore, the lack of a native version of a particular application did not preclude that application from your non-Intel NT machine. To the contrary, MS-DOS and Windows apps ran transparently on non-Intel versions of NT. But, I digress....
The issue was that Microsoft demanded that AIM pay for the development of NT/PPC. I presume that it demanded that DEC pay for the development of NT/Alpha. AIM and DEC refused Microsoft's demands. In turn, Microsoft dropped development of NT/PPC and NT/Alpha. It repurposed NT from a cross-platform OS to single-platform OS optimized for Intel x86.
Who told you that? The issue in the 1990s was not Office. The dominant word processor was Corel WordPerfect. The dominant spreadsheet was Lotus 1-2-3. Lack of Micrsoft Office was not a dealbreaker. That said, non-Intel versions of NT included an embedded version of SoftWindows to emulate Intel processors. Therefore, the lack of a native version of a particular application did not preclude that application from your non-Intel NT machine. To the contrary, MS-DOS and Windows apps ran transparently on non-Intel versions of NT. But, I digress....
What, you work in a law firm or something? Or are you remembering the wrong decade? The Excel/Word battle with Lotus 1-2-3/Wordperfect battle was over by 1993, during the Windows 3.x days. By the time Windows 95 rolled around, they were permanently boxed into their micro-niches.
The Windows emulation solutions in the 90s were not practical. What was needed was competitive performance with PPro systems. Pentium Pros were competitive to Alpha and PPC, and using emulation only hurt their brands. They really needed Office app performance to be faster than x86, and by factors of 1.5 or more.
Quote:
The issue was that Microsoft demanded that AIM pay for the development of NT/PPC. I presume that it demanded that DEC pay for the development of NT/Alpha. AIM and DEC refused Microsoft's demands. In turn, Microsoft dropped development of NT/PPC and NT/Alpha. It repurposed NT from a cross-platform OS to single-platform OS optimized for Intel x86.
Yes, right. Maybe AIM and DEC should have paid Microsoft for the ports of Office to NT/PPC and NT/Alpha. Money is amazing at convincing people to do things. That would have been the right thing to do. MS Windows and Office had >80% marketshare and x86 had >80% marketshare. It was plain stupid for them not to pay for it.
The Windows emulation solutions in the 90s were not practical. What was needed was competitive performance with PPro systems. Pentium Pros were competitive to Alpha and PPC, and using emulation only hurt their brands. They really needed Office app performance to be faster than x86, and by factors of 1.5 or more.
Having actually used an NT/Alpha machine, I most adamantly disagree. The only way that the user would have known that his Intel-based application was running on a completely different processor ISA was if someone told him.
Quote:
Originally Posted by Shrike
Yes, right. Maybe AIM and DEC should have paid Microsoft for the ports of Office to NT/PPC and NT/Alpha. Money is amazing at convincing people to do things. That would have been the right thing to do. MS Windows and Office had >80% marketshare and x86 had >80% marketshare. It was plain stupid for them not to pay for it.
So the truth is revealed. You want other companies to pay Microsoft to develop its own products. Microsoft screwed its partners and you cheered. Nice person, you.
Having actually used an NT/Alpha machine, I most adamantly disagree. The only way that the user would have known that his Intel-based application was running on a completely different processor ISA was if someone told him.
It was imperfect at best. A native port would have been 100x better. We can stop here and agree to disagree.
Quote:
So the truth is revealed. You want other companies to pay Microsoft to develop its own products. Microsoft screwed its partners and you cheered. Nice person, you.
Well, yes. If I was AIM or DEC (or Compaq, but if DEC was able to sell more, maybe Compaq wouldn't have bought them), I would have paid for native ports of Office and other MS applications. This is business. You do the things that allow you to sell your product and make money. Having Office in the 90s was the number 1 gate to being able to sell your computer system to businesses.
Once they decided not to do that, they relegated Alpha to the wrong business model (low volume workstation/server product lagging a generation behind in fab process), and they lost all chance to become relevant. How good was Steve Jobs? He convinced MS to build Office for Mac OS 9/X (and got them to do the symbolic gesture of buying 150m of non-voting AAPL). That deal meant Mac and Apple survived. It is the one big reason Macs are bought by companies.
Comments
True.
But Apple made that transition for its entire range of desktop and notebook computers.
It would not make sense for just one line of notebooks?
C.
Put an ARM emulator in XCode, and make it create fat binaries (x86 and ARM) by default. In fact, Apple can start doing it now, even with no ARM Mac. Yet
ARM architecturally is no less than x86, it is just that the focus of ARM is mobile, the MacBook Air is the ultimate mobile Mac. In fact if an ARM CPU were used, it can perform better and get better battery life. We now have 1GHz ARM CPUs in smartphones and this is without overheating and with acceptable battery life. The MacBook Air has the thermal envelope to handle a 2GHz ARM or even more.
They also don't seem to understand what architecture is and the vast difference between ARM and Intel. It is more than just the 32 bit or 64 bit question, the differences are vast. Further ARM can not effectively emulate an intel processor. Each time in the past when Apple has switched architectures they have done so when the new architecture was significantly faster so that emulation was viable.
I more than understand how ARM and x86 are different. PPC and x86 were vastly different, even in endianess. Before bringing a MacBook Air using an ARM CPU, Apple needs to make sure the fat binaries are out there.
The gap between ARM and x86 in performance is diminishing fast. ARM is eying the desktop market, the smartbook and netbook markets are but stepping stones.
When I say I would like a reason, I mean the reason why you want an ARM chip in a Mac?
Better battery life, less heat dissipation which means the CPU can be run at a higher clock rate, and even allow for a slimmer and lighter design.
Put an ARM emulator in XCode, and make it create fat binaries (x86 and ARM) by default. In fact, Apple can start doing it now, even with no ARM Mac. Yet
ARM architecturally is no less than x86, it is just that the focus of ARM is mobile, the MacBook Air is the ultimate mobile Mac. In fact if an ARM CPU were used, it can perform better and get better battery life. We now have 1GHz ARM CPUs in smartphones and this is without overheating and with acceptable battery life. The MacBook Air has the thermal envelope to handle a 2GHz ARM or even more.
I more than understand how ARM and x86 are different. PPC and x86 were vastly different, even in endianess. Before bringing a MacBook Air using an ARM CPU, Apple needs to make sure the fat binaries are out there.
The gap between ARM and x86 in performance is diminishing fast. ARM is eying the desktop market, the smartbook and netbook markets are but stepping stones.
Better battery life, less heat dissipation which means the CPU can be run at a higher clock rate, and even allow for a slimmer and lighter design.
It sounds like you believe ARM-based processors can eventually match the performance of Intel's x86-based processors while at the same time have lower heat dissipation and longer battery life. How do you propose ARM achieve this magic? I dislike the CISC to RISC code decoding overhead of modern x86 processors and wish x86 would go away as much as the next person, but we have no choice but to acknowledge that despite this legacy CISC overhead, Intel's x86 chips are highly optimized and efficient processors capable of beating out the best of the RISC world such as UltraSPARC and POWER. So I don't see how ARM-based designs can match x86 performance while achieving better efficiency. Current ARM-based chips are so efficient because they are just much simpler and less powerful than most x86 chips. They are just missing so much stuff compared to x86 processors, like deep pipelining, superscalar execution, out-of-order execution, branch prediction, macro-op fusion, barrel multithreading, that at the same clock speed they consume much less power than x86 processors because they are just much smaller cores. Sure, recent ARM designs have been adding stuff, Cortex A8 got a deep pipeline and superscalar execution, Cortex A9 added out-of-order execution and branch prediction. But the question is, once ARM-based cores get all this stuff that they are able to match x86 performance, will they be any more efficient?
It sounds like you believe ARM-based processors can eventually match the performance of Intel's x86-based processors while at the same time have lower heat dissipation and longer battery life. How do you propose ARM achieve this magic? I dislike the CISC to RISC code decoding overhead of modern x86 processors and wish x86 would go away as much as the next person, but we have no choice but to acknowledge that despite this legacy CISC overhead, Intel's x86 chips are highly optimized and efficient processors capable of beating out the best of the RISC world such as UltraSPARC and POWER. So I don't see how ARM-based designs can match x86 performance while achieving better efficiency. Current ARM-based chips are so efficient because they are just much simpler and less powerful than most x86 chips. They are just missing so much stuff compared to x86 processors, like deep pipelining, superscalar execution, out-of-order execution, branch prediction, macro-op fusion, barrel multithreading, that at the same clock speed they consume much less power than x86 processors because they are just much smaller cores. Sure, recent ARM designs have been adding stuff, Cortex A8 got a deep pipeline and superscalar execution, Cortex A9 added out-of-order execution and branch prediction. But the question is, once ARM-based cores get all this stuff that they are able to match x86 performance, will they be any more efficient?
And to answer your question, a resounding yes! Because it wont have decoding circuitry for complex instructions to simpler ones.
The only reason x86 can compete with POWER and UltraSPARC is due to Intel's sheer mount of resources it thrown into it. That and Sun didn't push UltraSPARC hard enough. Look at what Fujitsu managed to do with SPARC64. Going back to POWER, I don't think x86 compete, not on the server and supercomputer level. Just take a look at POWER7. IBM and Freescale did ignore PowerPC on the desktop, Apple was but a drop in the bucket for them and didn't warrant the investment needed to push PowerPC forward. But look what IBM managed to do with PowerPC for Microsoft. Unlike Apple, Microsoft was involved in the design and payed IBM a nice sum of cash.
Oh and why do you think Intel came up with Itanium and tried to push it hard? Intel wanted to transition to IA64, but killing x86 is something no one can do, not even Intel.
And to answer your question, a resounding yes! Because it wont have decoding circuitry for complex instructions to simpler ones.
The only reason x86 can compete with POWER and UltraSPARC is due to Intel's sheer mount of resources it thrown into it. That and Sun didn't push UltraSPARC hard enough. Look at what Fujitsu managed to do with SPARC64. Going back to POWER, I don't think x86 compete, not on the server and supercomputer level. Just take a look at POWER7. IBM and Freescale did ignore PowerPC on the desktop, Apple was but a drop in the bucket for them and didn't warrant the investment needed to push PowerPC forward. But look what IBM managed to do with PowerPC for Microsoft. Unlike Apple, Microsoft was involved in the design and payed IBM a nice sum of cash.
Oh and why do you think Intel came up with Itanium and tried to push it hard? Intel wanted to transition to IA64, but killing x86 is something no one can do, not even Intel.
So perhaps ARM will turn out to be the x86 killer? Haha, that would be nice. It does have the advantage of not incurring the x86 decoding overhead, but there's still an enormous hurdle to climb: the billions Intel pours hand designing its chips and building foundries with the best fab processes. Time and time again we see superior architectures falter against this might, it's almost like a tragic tale. I always thought Sun would be the one to finally do x86 in (the MAJC sounds like such a great idea!) but it looks like all those chip designers they have were goofing off half the time, and now that hope is no longer possible. It would be interesting, to say the least, if an ARM-based design turns out to achieve the impossible.
Put an ARM emulator in XCode, and make it create fat binaries (x86 and ARM) by default. In fact, Apple can start doing it now, even with no ARM Mac. Yet
Apple already does have an Arm emulator in XCode. But again I question the wisdom of making a processor shift for just one line of product, which is (by all accounts) not Apple's best selling notebook.
Apple makes two main lines.
Media centric portable appliances. iPhone, iPad, iPod.
Productivity focussed computers. Macs (desktops and notebooks)
There's a simple strategy here with processors. The portable media devices run ARM while the computers run Intel.
So while I agree that an Arm-powered Macbook Air is possible. I think the costs of porting not just Mac OS, but all drivers and all third party applications just for one notebook line is not justifiable.
C.
Battery life, less heat dissipation which means the CPU can be run at a higher clock rate, and even allow for a slimmer and lighter design.
So you want a slower, thinner MacBook Air then.
And to answer your question, a resounding yes! Because it wont have decoding circuitry for complex instructions to simpler ones.
The only reason x86 can compete with POWER and UltraSPARC is due to Intel's sheer mount of resources it thrown into it. That and Sun didn't push UltraSPARC hard enough. Look at what Fujitsu managed to do with SPARC64. Going back to POWER, I don't think x86 compete, not on the server and supercomputer level
On the supercomputer level x86 certainly competes. It's cheap, easily available, most scientific software is developed heavily on it...
While I've run jobs on Blue Gene systems, the majority of the clusters I run on, and the majority of "supercomputer" class clusters out there in general are x86 based.
Take a gander at the top500 if you dont believe me. Also, while I'm not sure if its up on the site, at the top500 presentation at supercomputing they usually go through a very interesting set of breakdown numbers and graphs to go along with them comparing current architecture to historical trends - if it's up should be good reading if you're interesting in exploring the numbers further.
On topic though:
No way the Air switches to ARM, it would lose too much compatibility with mainstream osx software. Also, the air is competing in the relatively high-end, work-usable sub-notebook category, not the netbook/media category the iPad seems to be aimed at, no reason they cant co-exist.
On the supercomputer level x86 certainly competes. It's cheap, easily available, most scientific software is developed heavily on it...
While I've run jobs on Blue Gene systems, the majority of the clusters I run on, and the majority of "supercomputer" class clusters out there in general are x86 based.
Take a gander at the top500 if you dont believe me. Also, while I'm not sure if its up on the site, at the top500 presentation at supercomputing they usually go through a very interesting set of breakdown numbers and graphs to go along with them comparing current architecture to historical trends - if it's up should be good reading if you're interesting in exploring the numbers further.
On topic though:
No way the Air switches to ARM, it would lose too much compatibility with mainstream osx software. Also, the air is competing in the relatively high-end, work-usable sub-notebook category, not the netbook/media category the iPad seems to be aimed at, no reason they cant co-exist.
The processor used in cluster nodes is interesting, but is hardly indicative of much in and of itself. For one thing, the power of a cluster is determined by the number of nodes in the cluster. Need more power? Add more nodes. This is one of the consequences of the fact that x86-based nodes are cheap, a fact that you got absolutely correct.
Aizmov is also absolutely correct. IBM had turned its attention away from personal computing to concentrate on workstations and servers. A PPC G3 did not generate enough heat to incubate an egg. IBM had a distinct advantage over Intel. However, the G5 generated enough heat to fry an egg. OTOH, Intel had developed new fab techniques that substantially reduced heat generation in its processors. A G4-based laptop would scorch your clothing. A G5-based laptop was impossible. However, IBM did not care. At least, not until Apple announced that it would switch to Intel.
In terms of shear computing power, the POWER/PowerPC architecture was plenty powerful. It bears remembering that at the time IBM was still selling low-priced workstations based on the PPC 604, the same processor used in the Power Macintosh 9500. The G5 smoked the PPC 604. Without question, Intel-based Macs are more powerful than comparable PPC-based Macs of yore. However, the performance advantage is largely determined by the processor clock speed and the number of cores.
What is this all getting to? The POWER7 seems to indicate that IBM has finally seen the light. At 4.1 GHz, its clock speed is faster than anything that Intel has on the market. It also eight cores per processor. It also appears to generate substantially less heat than the old POWER processor modules. In terms of hardware capability, IBM appears to have a big winner.
Now for the issue of software. For scientific computing, you are just plain wrong. Computational science programs are written in FORTRAN or C/C++. These programs are compiled on the target computer using standard open source or commercial compilers. Optimization is done within the compiler. Unlike commercial apps, computational science programs are rarely optimized by hand to maximize performance.
That said, they can still be extremely effective in more controlled environments where you can prevent chaos in the cache. The iPhone is a good example: it runs one user process at a time.
If you were to beef-up an ARM with a sophisticated, large cache and a powerful, vector FPU, then it wouldn't be that much more efficient than a comparable x86.
The processor used in cluster nodes is interesting, but is hardly indicative of much in and of itself. For one thing, the power of a cluster is determined by the number of nodes in the cluster. Need more power? Add more nodes. This is one of the consequences of the fact that x86-based nodes are cheap, a fact that you got absolutely correct.
Aizmov is also absolutely correct. IBM had turned its attention away from personal computing to concentrate on workstations and servers. A PPC G3 did not generate enough heat to incubate an egg. IBM had a distinct advantage over Intel. However, the G5 generated enough heat to fry an egg. OTOH, Intel had developed new fab techniques that substantially reduced heat generation in its processors. A G4-based laptop would scorch your clothing. A G5-based laptop was impossible. However, IBM did not care. At least, not until Apple announced that it would switch to Intel.
In terms of shear computing power, the POWER/PowerPC architecture was plenty powerful. It bears remembering that at the time IBM was still selling low-priced workstations based on the PPC 604, the same processor used in the Power Macintosh 9500. The G5 smoked the PPC 604. Without question, Intel-based Macs are more powerful than comparable PPC-based Macs of yore. However, the performance advantage is largely determined by the processor clock speed and the number of cores.
What is this all getting to? The POWER7 seems to indicate that IBM has finally seen the light. At 4.1 GHz, its clock speed is faster than anything that Intel has on the market. It also eight cores per processor. It also appears to generate substantially less heat than the old POWER processor modules. In terms of hardware capability, IBM appears to have a big winner.
Now for the issue of software. For scientific computing, you are just plain wrong. Computational science programs are written in FORTRAN or C/C++. These programs are compiled on the target computer using standard open source or commercial compilers. Optimization is done within the compiler. Unlike commercial apps, computational science programs are rarely optimized by hand to maximize performance.
Perhaps poorly phrased by me on the "scientific software" comment, what I meant by
On the supercomputer level x86 certainly competes. It's cheap, easily available, most scientific software is developed heavily on it.
is that most scientific software [used on supercomputers] is heavily developed on x86 clusters because of the availability, not that it wont run on other arches. I was talking about the heavy usage of x86 in scientific/supercomputing work, not the limitations of the software. (Disclaimer here: I both work on several clusters, and heavily use for research several different highly scalable, cluster-targeted, modeling tools.)
I dont disagree with you on the advances in other arches. POWER/PowerPC are far nicer than x86 as an arch, and I'm rather fond of sparc machines. The most powerful machine I currently can and do run jobs on is NY Blue (http://www.bnl.gov/newyorkblue/), which is most definitely not x86!
If you look at what I was replying to I was simply refuting Aizmov's claim:
I don't think x86 compete, not on the server and supercomputer level
You seem to say that because licensing out chip designs works for ARM, Intel would have no problem doing it.
No the point is if they want to compete with ARM they need to be able to work with customers to offer up custom solutions. They don't have to actually license out the core. What they do need is a different model than the one where every customer gets what Intel designed and though was needed on a SoC. What is notable about ATOM is that it is pathetic with respect to integration especially compared to what the ARM world offers up.
What you are ignoring is that Intel operates with an entirely different business model.
Nope, what I'm saying is that their business model needs to change to compete with ARM based devices.
They don't license out their chip related designs to just anyone, and they are not a foundry. As far as I know they've never manufactured anyone else's chips with their fabs. And just look at the history of Intel's licensing terms with their CPU-related designs. The x86 licensing terms with AMD went through several court battles, and Intel has threatened to withdraw its cross-licensing deal with AMD should AMD split up into a chip designer and a foundry.
Well a time will come when the ability to force licenses of x86 will be gone.
And Intel has refused to license DMI, another technology that's important for their chip designs, to nvidia. There have been no indications that Intel will dramatically change their business model and start licensing out their designs or start becoming a foundry for other chip designers, so it's only rational to expect the status quo to continue. It's far more likely that Intel will attempt to make their own SoC design than work out some kind of deal that they've never done before with someone else.
Well Intel is way to late to the SoC party. As to their attempt to manipulate the market by restricting licensing I have a funny feeling that their ability to do that will be very limited in the future as the government takes notice.
Dave
No the point is if they want to compete with ARM they need to be able to work with customers to offer up custom solutions. They don't have to actually license out the core. What they do need is a different model than the one where every customer gets what Intel designed and though was needed on a SoC. What is notable about ATOM is that it is pathetic with respect to integration especially compared to what the ARM world offers up.
Nope, what I'm saying is that their business model needs to change to compete with ARM based devices.
Well a time will come when the ability to force licenses of x86 will be gone.
Well Intel is way to late to the SoC party. As to their attempt to manipulate the market by restricting licensing I have a funny feeling that their ability to do that will be very limited in the future as the government takes notice.
Dave
Oh I see what you are saying. Perhaps Intel would need to adopt the ARM model to have success in the SoC market. But I could see Intel just going the "this is our SoC and you will use it and you will like it" route.
That would be pretty weird. Intel would have to license x86 and QPI/DMI to Apple for PA Semi to design the SoC chip package, and Apple would then license it back to Intel for Intel to make it (I don't see Intel opening up its fabs to make chips for someone else, so Apple would have to license the SoC to Intel). Or Apple and Intel could make a cross-licensing deal, but that may have other PC manufacturers up in arms
Why would intel have to license anything from Apple? It would be a custom order.
And it's unlikely Intel will do cross-licensing with an ARM licensee, since Intel has their rival Atom platform.
If they did business like that they would have any customers. Hell, they do business with AMD. Why? Because there is money to be made.
Oh I see what you are saying. Perhaps Intel would need to adopt the ARM model to have success in the SoC market. But I could see Intel just going the "this is our SoC and you will use it and you will like it" route.
But I don't see them being successful. Besides that ARM is being very aggressive going after the latest process technologies thus enabling even higher integration, lower power and faster performance. Last I heard ARM is already working towards Cortex on a 28nm process. That may be a way off but what it says is that Intel doesn't have a process technology advantage anymore. If anything ARMs smaller cores effectively give them advantages a process step or two behind Intel.
The important thing to take out of the process discussion is that the shrinking processes and ARMs smaller cores mean that SoC built with the tech can economically have higher integration and more features. Sure the performance is nice, but it is cost that make ARM so attractive. Just try to imagine fitting a ATOM into an iPhone in an economic manner.
Dave
The economics simply aren't feasible anymore. It basically ended when DEC and AIM couldn't convince MS to port Office to NT/Alpha and NT/PPC in the 90s.
I do believe the iPad-ization of computing is possible where the majority of computing devices are ARM devices like handheld and slate form factors, but for your traditional laptop and desktop space, Intel has basically won, and will be in those systems until something other than CMOS-based chips takes over.
To reiterate, a MBA with a Core i3 will absolutely destroy any ARM machine in any performance metric by a factor of 4 or more. The only metric ARM can be competitive in is standby time and battery burn down time. Now, if all you want your MBA to do is iPad like tasks, an ARM-based MBA could be interesting, but Apple won't be selling any of those for $1500. And hence, Apple won't even be offering such a system.
...
The economics simply aren't feasible anymore. It basically ended when DEC and AIM couldn't convince MS to port Office to NT/Alpha and NT/PPC in the 90s.
....
Who told you that? The issue in the 1990s was not Office. The dominant word processor was Corel WordPerfect. The dominant spreadsheet was Lotus 1-2-3. Lack of Micrsoft Office was not a dealbreaker. That said, non-Intel versions of NT included an embedded version of SoftWindows to emulate Intel processors. Therefore, the lack of a native version of a particular application did not preclude that application from your non-Intel NT machine. To the contrary, MS-DOS and Windows apps ran transparently on non-Intel versions of NT. But, I digress....
The issue was that Microsoft demanded that AIM pay for the development of NT/PPC. I presume that it demanded that DEC pay for the development of NT/Alpha. AIM and DEC refused Microsoft's demands. In turn, Microsoft dropped development of NT/PPC and NT/Alpha. It repurposed NT from a cross-platform OS to single-platform OS optimized for Intel x86.
Who told you that? The issue in the 1990s was not Office. The dominant word processor was Corel WordPerfect. The dominant spreadsheet was Lotus 1-2-3. Lack of Micrsoft Office was not a dealbreaker. That said, non-Intel versions of NT included an embedded version of SoftWindows to emulate Intel processors. Therefore, the lack of a native version of a particular application did not preclude that application from your non-Intel NT machine. To the contrary, MS-DOS and Windows apps ran transparently on non-Intel versions of NT. But, I digress....
What, you work in a law firm or something? Or are you remembering the wrong decade? The Excel/Word battle with Lotus 1-2-3/Wordperfect battle was over by 1993, during the Windows 3.x days. By the time Windows 95 rolled around, they were permanently boxed into their micro-niches.
The Windows emulation solutions in the 90s were not practical. What was needed was competitive performance with PPro systems. Pentium Pros were competitive to Alpha and PPC, and using emulation only hurt their brands. They really needed Office app performance to be faster than x86, and by factors of 1.5 or more.
The issue was that Microsoft demanded that AIM pay for the development of NT/PPC. I presume that it demanded that DEC pay for the development of NT/Alpha. AIM and DEC refused Microsoft's demands. In turn, Microsoft dropped development of NT/PPC and NT/Alpha. It repurposed NT from a cross-platform OS to single-platform OS optimized for Intel x86.
Yes, right. Maybe AIM and DEC should have paid Microsoft for the ports of Office to NT/PPC and NT/Alpha. Money is amazing at convincing people to do things. That would have been the right thing to do. MS Windows and Office had >80% marketshare and x86 had >80% marketshare. It was plain stupid for them not to pay for it.
...
The Windows emulation solutions in the 90s were not practical. What was needed was competitive performance with PPro systems. Pentium Pros were competitive to Alpha and PPC, and using emulation only hurt their brands. They really needed Office app performance to be faster than x86, and by factors of 1.5 or more.
Having actually used an NT/Alpha machine, I most adamantly disagree. The only way that the user would have known that his Intel-based application was running on a completely different processor ISA was if someone told him.
Yes, right. Maybe AIM and DEC should have paid Microsoft for the ports of Office to NT/PPC and NT/Alpha. Money is amazing at convincing people to do things. That would have been the right thing to do. MS Windows and Office had >80% marketshare and x86 had >80% marketshare. It was plain stupid for them not to pay for it.
So the truth is revealed. You want other companies to pay Microsoft to develop its own products. Microsoft screwed its partners and you cheered. Nice person, you.
Having actually used an NT/Alpha machine, I most adamantly disagree. The only way that the user would have known that his Intel-based application was running on a completely different processor ISA was if someone told him.
It was imperfect at best. A native port would have been 100x better. We can stop here and agree to disagree.
So the truth is revealed. You want other companies to pay Microsoft to develop its own products. Microsoft screwed its partners and you cheered. Nice person, you.
Well, yes. If I was AIM or DEC (or Compaq, but if DEC was able to sell more, maybe Compaq wouldn't have bought them), I would have paid for native ports of Office and other MS applications. This is business. You do the things that allow you to sell your product and make money. Having Office in the 90s was the number 1 gate to being able to sell your computer system to businesses.
Once they decided not to do that, they relegated Alpha to the wrong business model (low volume workstation/server product lagging a generation behind in fab process), and they lost all chance to become relevant. How good was Steve Jobs? He convinced MS to build Office for Mac OS 9/X (and got them to do the symbolic gesture of buying 150m of non-voting AAPL). That deal meant Mac and Apple survived. It is the one big reason Macs are bought by companies.