And what else would you expect them to say? Even if they actually believe it, they're still seeing everything from their own eyes, from their point of view, and their market, just like an incumbent of an "old" technology would.
There is nothing in the instruction set that is more or less energy efficient than any other instruction set
Oh, come on. The problem with x86 is that it's a variable length instruction encoding that isn't self synchronizing. That is, you can start reading at byte 0 and read one set of valid instruction or you can start reading at byte 1 and read another completely different set of valid instructions.
This means that the logic to decode more than one instruction in a clock cycle is really complicated, and complicated means power intensive. For instance, in AMD's Bulldozer chip the instruction decode unit uses more power than the integer execution cluster. Now, ARM has its troubles too (instruction predication on every instruction means another logical dependency, meaning that if you go out of order your scoreboard is more complicated) but they're not as bad and don't really exist in alternate encoding like Thumb2 or the 64 bit one.
Intel is able to compete so well because they tend to have better fabs, they tend to reach a given node like 22nm before everyone else, and their performance on that node tends to be better than other players too. But x86 does have intrinsic disadvantages.
The relative overhead of x86 vs other instruction set's is meaningless next to intel's current process advantages. ARM is only viable when you have a similar investment in design AND operate on the same manufacturing process.
I feel that a lot of sw folks have a lack of imagination when it comes to hw. A lot of very smart people here work on making an efficient, fast front-end. There's lots of research in this area. To my eyes, the implementations are stunning.
To say that a variable-length CISC instruction set can never be as fast or effecient as ARM is sort-of like saying that an interpreted language can never be as fast as C. And we all know how that goes over on HN.
I'm sure the front end has had a lot of work and cleverness put into it, and I'm sure that it's able to, say, correctly guess where instruction boundaries are more than 99% of the time without knowing for sure and then remove those instructions from the queue if it turns out that the guess was wrong. But that just means that 4-wide decode is only on the same order of power consumption as execution, instead of being an order of magnitude more like if you'd done thing the naive way. I'm sure that the work they do _is_ stunning, but its work that doesn't even have to be done on more regular instruction sets.
It's not a problem with being variable length or CISC, its a problem with the lack of self-synchronization. If you, say, had 8 or 16 bit blocks were first bit of each block told you whether it was the beginning of an instruction you wouldn't have this problem at all. I'd generally say that for a modern general purpose computer variable length instructions and a large number of op-codes are a good idea, though a large number of addressing modes seems to still be a disadvantage. Its probably no accident that ARM, the "CISCiest" of the RISC processors is so popular right now.
But don't ARM/Marvell/Qualcomm/Nvidia have a lot of smart people working on making an efficient fast front-end?
Overcoming an obstacle is great, but I feel like companies who don't have to overcome that obstacle can focus their energy on other aspects of the product.
Android is no problem because of the Dalvik byte code engine but Apple is a whole other matter. Apple has over 600,000 apps in the App Store that are all coded for ARM. Moving to a new instruction set architecture is going to problematic.
If Intel had taken low power seriously back in the days of the Newton and the StrongARM (which Intel actually owned for a while) they might have won the Apple business instead of ARM back in 2007 but now it is probably too late.
Apple has switched CPU architectures before but never with the number of applications that they are currently dealing with in the App Store.
I would think that there would be few problems porting your source from ARM to x86. Heck, if you use the iOS simulator, it compiles to x86! Maybe a Rosetta like shim could be used for apps where the authors do not update them.
I don't think it would take much to recompile existing apps but there are so many apps, just approving them would take Apple years.
Then think of the all the apps that are tuned to take maximum advantage of the platform. That code may work but it doesn't mean it will work optimally.
Intel is going to have to do a lot better than "we win some, lose some" on battery and performance to convince Apple to switch.
The last time Apple did this apps didn't have to re-compile - the Rosetta translation layer did a pretty decent job. If Apple were to switch architectures (rather unlikely, but still) I imagine they'd be providing a similar sort of translation layer for most apps to use.
You aren't going to use Rosetta style software on a battery constrained mobile device. There would have to be a huge benefit to switching to make that kind of problem for users. The iPhone is already bashed for having battery issues. What would be the benefit of switching to Intel for Apple?
> Apple has switched CPU architectures before but never with the number of applications that they are currently dealing with in the App Store.
All that would require is Apple to say that all ARM iOS apps don't work on x86 version of iOS. It's not like Apple currently even guarantees an App from the store will work between iOS versions. The need to update apps for an architecture change would simply be pushed to the developers, just like it is now for iOS versions.
Arch changes wouldn't be a problem for Apple; besides having done it before, they don't have an issue with forcing devs to make major changes if it makes the platform better.
However, it's unlikely Apple would switch to x86 unless Intel was willing to license the spec (Intel would much rather make the chips); as ARM licensing allows them near-full control over their chipset vs being dependent on a third party.
> unless Intel was willing to license the spec (Intel would much rather make the chips); as ARM licensing allows them near-full control over their chipset vs being dependent on a third party.
Intel's lack of customization is the real problem. NVidia, Apple, Samsung, TI, and Qualcomm can build amazingly specific chips to the task of mobile, while Intel wants a one size fits all solution. Intel has effectively removed all the chipset makers from the PC world giving us poorer performing PCs. This approach won't work in mobile.
From a mobile OEM's perspective (excepting Apple and Samsung, who have the capability to produce their own SoCs), besides arch there's very little difference between Intel and other SoC vendors. Snapdragon, Tegra, and OMAP all leave about as much room for customization as Medfield (the mobile Atom variant) does. Qualcomm actually goes a step further than most and packs the modem into the SoC itself. This is partially why you see so many international phones using a different SoC end up swapping for a Snapdragon in the US. Qualcomm was heavily involved in the LTE spec, ensuring they had a head start on modems vs. the rest. Thus when American carriers demand LTE (or DC-HSPA in T-Mobile's case), it's then easier for OEMs to use a Qualcomm part vs. wait on a competitor's part to be approved and be late to market.
Since Apple and Samsung are the majority of the market at this point, it makes a big difference.
Beyond that, you have a number of vendors able to use ARM cores to make product. Never mind AMD getting using ARM cores. Intel has a chipset they want to sell everyone. The ARM ecosystem consists of multiple solutions from multiple vendors all with the core CPU software being the same.
Apple has no reason whatsoever to switch to Intel for tablets anyway. Even if Intel's chips would be slightly better for that power consumption level, which they aren't, they're maybe half as good, it wouldn't be worth it for Apple to switch.
Not to mention that now Apple has almost full control over their chip, so why would they give that up? I don't know what Tim Cook will do in the future, but if Steve Jobs was still alive, I'm pretty sure he would've switched to ARM for Macbook Air or perhaps a "next-gen Macbook Air" to a 64 bit ARM chip in 2014-2015.
Look at the new iPad and its ARM chip. It can already support well enough a 2k resolution. Can Intel Atom do that right now? I doubt it. Medfield, their "low-power" Atom that is supposed to compete with ARM, can only support 1024x600 right now.
>Android is no problem because of the Dalvik byte code engine
I work for a device manufacturer that went with Intel for a product - and x86 is a huge problem regardless of Dalvik.
The fact is, most popular apps out there, and essentially all games, have a portion of their code running in JNI (C libraries called by Java) for performance reasons. It pretty much wiped out half of the Android Market as incompatible and had software partners screaming at us.
Who cares about a tablet/cell phone's CPU?
It's the GPU that matters.
So I buy an Nvidia Tegra2 chipset, it happens to have an ARM tucked in the corner. I buy an Atom and it has the latest in a long line of Intel embedded GPUS stuck int he corner as an afterthought
Old ones. Almost 2 generations old. They can barely get half of the performance of any other current high-end chip, and Mali T604 and Adreno 320 should be out in a few months with another 2-3x increase in performance.
I completely agree. Pushing pixels is WAY more expensive then executing general code in a mobile app (and usually in desktop apps too). Deserializing a view structure and presenting it to the screen is going to be limited by i/o and gpu drawing. Data crunching just isn't a big thing on mobile devices, aside from game physics or potentially custom video/image processing.
Generally when a company dismisses a competitor in this way it usually finds itself on the wrong end of a disruptive collapse in 5 or so years. See Nokia, RIM, Palm.
While its difficult to bet against Intel, it will be interesting to see how quickly they can ramp up sales of their mobile processors as sales of their desktop processors decline. That will be the key to Intel's survival.
On a somewhat unrelated note, Intel's cleanroom ad [1] that is reproduced in the article really sets my teeth on edge because of the sheer level of misogyny involved (little girl with toys in a pink bedroom vs. grown men in blue high-tech room).
Could it possibly send a stronger message that women don't belong in tech?
(That the ad designers may not have intended that message does not mean that it's not there.)
32 comments
[ 2.9 ms ] story [ 74.0 ms ] threadOh, come on. The problem with x86 is that it's a variable length instruction encoding that isn't self synchronizing. That is, you can start reading at byte 0 and read one set of valid instruction or you can start reading at byte 1 and read another completely different set of valid instructions.
This means that the logic to decode more than one instruction in a clock cycle is really complicated, and complicated means power intensive. For instance, in AMD's Bulldozer chip the instruction decode unit uses more power than the integer execution cluster. Now, ARM has its troubles too (instruction predication on every instruction means another logical dependency, meaning that if you go out of order your scoreboard is more complicated) but they're not as bad and don't really exist in alternate encoding like Thumb2 or the 64 bit one.
Intel is able to compete so well because they tend to have better fabs, they tend to reach a given node like 22nm before everyone else, and their performance on that node tends to be better than other players too. But x86 does have intrinsic disadvantages.
I feel that a lot of sw folks have a lack of imagination when it comes to hw. A lot of very smart people here work on making an efficient, fast front-end. There's lots of research in this area. To my eyes, the implementations are stunning.
To say that a variable-length CISC instruction set can never be as fast or effecient as ARM is sort-of like saying that an interpreted language can never be as fast as C. And we all know how that goes over on HN.
It's not a problem with being variable length or CISC, its a problem with the lack of self-synchronization. If you, say, had 8 or 16 bit blocks were first bit of each block told you whether it was the beginning of an instruction you wouldn't have this problem at all. I'd generally say that for a modern general purpose computer variable length instructions and a large number of op-codes are a good idea, though a large number of addressing modes seems to still be a disadvantage. Its probably no accident that ARM, the "CISCiest" of the RISC processors is so popular right now.
Overcoming an obstacle is great, but I feel like companies who don't have to overcome that obstacle can focus their energy on other aspects of the product.
If Intel had taken low power seriously back in the days of the Newton and the StrongARM (which Intel actually owned for a while) they might have won the Apple business instead of ARM back in 2007 but now it is probably too late.
Apple has switched CPU architectures before but never with the number of applications that they are currently dealing with in the App Store.
Then think of the all the apps that are tuned to take maximum advantage of the platform. That code may work but it doesn't mean it will work optimally.
Intel is going to have to do a lot better than "we win some, lose some" on battery and performance to convince Apple to switch.
All that would require is Apple to say that all ARM iOS apps don't work on x86 version of iOS. It's not like Apple currently even guarantees an App from the store will work between iOS versions. The need to update apps for an architecture change would simply be pushed to the developers, just like it is now for iOS versions.
However, it's unlikely Apple would switch to x86 unless Intel was willing to license the spec (Intel would much rather make the chips); as ARM licensing allows them near-full control over their chipset vs being dependent on a third party.
Intel's lack of customization is the real problem. NVidia, Apple, Samsung, TI, and Qualcomm can build amazingly specific chips to the task of mobile, while Intel wants a one size fits all solution. Intel has effectively removed all the chipset makers from the PC world giving us poorer performing PCs. This approach won't work in mobile.
Beyond that, you have a number of vendors able to use ARM cores to make product. Never mind AMD getting using ARM cores. Intel has a chipset they want to sell everyone. The ARM ecosystem consists of multiple solutions from multiple vendors all with the core CPU software being the same.
Not to mention that now Apple has almost full control over their chip, so why would they give that up? I don't know what Tim Cook will do in the future, but if Steve Jobs was still alive, I'm pretty sure he would've switched to ARM for Macbook Air or perhaps a "next-gen Macbook Air" to a 64 bit ARM chip in 2014-2015.
Look at the new iPad and its ARM chip. It can already support well enough a 2k resolution. Can Intel Atom do that right now? I doubt it. Medfield, their "low-power" Atom that is supposed to compete with ARM, can only support 1024x600 right now.
I work for a device manufacturer that went with Intel for a product - and x86 is a huge problem regardless of Dalvik.
The fact is, most popular apps out there, and essentially all games, have a portion of their code running in JNI (C libraries called by Java) for performance reasons. It pretty much wiped out half of the Android Market as incompatible and had software partners screaming at us.
So I buy an Nvidia Tegra2 chipset, it happens to have an ARM tucked in the corner. I buy an Atom and it has the latest in a long line of Intel embedded GPUS stuck int he corner as an afterthought
If the heaviest tasks are playing HD video, using webgl or playing 3D games then the GPU matters most.
If you are using your cell phone for massively parralel computation fluid dynamic simulation of nuclear weapons - then that's still the GPU.
If you are using it for I/O bound limited multi-tasking like database access or payroll processing then a 4core CPU is best.
There is no doubt in my mind that Apple will jump to Intel mobile chips as soon as Intel can meet Apple's needs.
Number one compelling reason: Samsung is Apple's foundry.
While its difficult to bet against Intel, it will be interesting to see how quickly they can ramp up sales of their mobile processors as sales of their desktop processors decline. That will be the key to Intel's survival.
Why will their sales of desktop processors decline?
If the iPad/Android/Windows 8 tablet doesn't have an Intel processor in it then that's money lost for Intel.
Could it possibly send a stronger message that women don't belong in tech?
(That the ad designers may not have intended that message does not mean that it's not there.)
[1] http://cleanroom.net/?p=966