3 ms·
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
by thoughtsimple 14y ago
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.
- jevinskie 14y agoI 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.
- thoughtsimple 14y agoI 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.
- objclxt 14y agoThe 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.
- thoughtsimple 14y agoYou 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?
- gnaffle 14y agoThey could even ship a device with an ARM core in addition to the Intel core, and only activate the Intel core for games etc.
- mhurron 14y ago> 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.
- ConstantineXVI 14y agoArch 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.
- protomyth 14y ago> 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.
- ConstantineXVI 14y agoFrom 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.
- protomyth 14y agoSince 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.
- mtgx 14y agoApple 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.
- listic 14y agoIs 1024x600 actually a CPU limitation? Do you have the source for that? (really curious)
- walexander 14y ago>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.