Intel's Plans For X86 Android, Smartphones, and Tablets 151
MrSeb writes "'Last week, Intel announced that it had added x86 optimizations to Android 4.0, Ice Cream Sandwich, but the text of the announcement and included quotes were vague and a bit contradictory given the open nature of Android development. After discussing the topic with Intel we've compiled a laundry list of the company's work in Gingerbread and ICS thus far, and offered a few of our own thoughts on what to expect in 2012 as far as x86-powered smartphones and tablets are concerned.' The main points: Intel isn't just a chip maker (it has oodles of software experience); Android's Native Development Kit now includes support for x86 and MMX/SSE instruction sets and can be used to compile dual x86/ARM, 'fat' binaries; and development tools like Vtune and Intel Graphics Performance Analyzer are on their way to Android."
Re:Intel's Software Experience...Graphics (Score:5, Informative)
have you used intel graphics lately(stuff they're shipping in 2011)? it's like having a discrete mobile gpu from 2004.
but this article is not news of any kind. intel has had these plans out in public for years and years, android ndk has support for multiple targets. if they actually started shipping _that_ would be news.
Comment removed (Score:4, Informative)
Re:Intel Softcores (Score:5, Informative)
What I would like to see is Intel creating a SoC and softcore suite
They did that, what, 18 months ago now? Total number of people who licensed it: zero. Why? Because x86 absolutely sucks for low power.
Lots of experience in chip design. I don't see why they can't create an ARM-Core competitor
Ah yes, all those massive commercial success stories that Intel has had when it tried to produce a non-x86 chip, like the iAPX, the i860, the Itanium. The closest they came was XScale, and they sold the team responsible for that to Marvell.
They can start from scratch. Unlike ARM there is no need to legacy support or backward compatibility.
Intel has two advantages over their competition: superior process technology and x86 compatibility. Your plan is that they should give up one of those?
They have produced great x86 compilers for years, so producing a new compiler for a new chip shouldn't be too difficult since they are already experienced with x86 and Itanium
Hahahaha! Spoken like someone who has never been involved with compiler design or spoken to any compiler writers. Tuning a compiler for a new architecture is not a trivial problem.
Re:Intel Softcores (Score:5, Informative)
The mistake most people seem to make here is to compare ARM to IA32, when they should be comparing ARM to Intel64/AMD64 (x86_64) since even Atom can run 64-bit code these days.
Going to 64-bit does increase code size a bit, but one of the good things about x86/x86_64 code is that it is VERY dense. This document
http://www.csl.cornell.edu/~vince/papers/iccd09/iccd09_density.pdf [cornell.edu]
suggests that 64-bit x86 code is actually even denser than ARM-thumb code in most cases (which in turn is denser than "normal" ARM code).
High code density means more cache hits, which means better performance and less power-hungry.
x86_64 has the same amount of integer registers as ARM: 16. Every single x86_64 CPU has support for SSE, which means that floating point operations can (and is) handled by the 16 SSE registers instead of the old x87 fpu-stack.
Fact is that the 64-bit specification for x86 fixed a large number of problems that the 32-bit specification had, making x86_64 a really good architecture without any significant flaws.
Re:power consumption (Score:5, Informative)
Is the display really that much of a hog on a cell phone? Those numbers sound like laptop numbers, but I thought we were talking cell phones.
My phone has a battery that holds around 1300 mAh at 3.7v. That means I can draw 4.8W for 1 hour. If my phone's display really sucked down even 10W, then I wouldn't be able to have the display on for more than about 28 minutes total, which doesn't match my experience at all. I regularly browse the web from my phone for a half hour at a time, without making much of a dent in the battery.
A quick scan through this paper [usenix.org] suggests backlight power for the phone they analyzed tops out at 414mW, and the LCD display power ranges from 33.1mW to 74.2mW. If you drop the brightness back just a few notches, the total display power is around a quarter Watt or so, which sounds far more reasonable.
I don't think Intel is standing still on power consumption. Their desktop CPUs are hogs, sure, but they can bring a lot of engineers to bear optimizing Atom-derived products. (We might get an early read from Knight's Corner, actually, although I expect it to still be on the "hot" side. I'm waiting to hear more about it.) Also, ARM's latest high-end offerings (including the recently announced A15) aren't exactly as power-frugal as some of their past devices. In the next couple years, I think the scatter plot of power vs. performance for ARM and x86 variants will show a definite overlap in the mix, with some x86s pulling less power than some ARMs.
Re:x86 (Score:4, Informative)
Similar to your design, the Tegra 3 ARM SoC does that. It has a quad-core A9 running at 1.5GHz or more, but it also has a "slow" core running at 600MHz or so. When things are idling, the slow core takes over and does the job while the hefty quadcores are powered off, saving tons of power.
Marvell I think also has a similar idea for their SoCs. And ARM's A15 design is supposed to incorporate that as well.