Slashdot Mirror
Android On Intel x86 Tablet Performance Explored: Things Are Improving
MojoKid writes: For the past few years, Intel has promised that its various low-power Atom-based processors would usher in a wave of low-cost Android and Windows mobile products that could compete with ARM-based solutions. And for years, we've seen no more than a trickle of hardware, often with limited availability. Now, that's finally beginning to change. Intel's Bay Trail and Merrifield SoCs are starting to show up more in full-featured, sub-$200 devices from major brands. One of the most interesting questions for would-be x86 buyers in the Android tablet space is whether to go with a Merrifield or Bay Trail Atom-based device. Merrifield is a dual-core chip without Hyper-Threading. Bay Trail is a quad-core variant and a graphics engine derived from Intel's Ivy Bridge Core series CPUs. That GPU is the other significant difference between the two SoCs. With Bay Trail, Intel is still employing their own graphics solution, while Merrifield pairs a dual-core CPU with a PowerVR G6400 graphics core. So, what's the experience of using a tablet running Android on x86 like these days? Pretty much like using an ARM-based Android tablet currently, and surprisingly good for any tablet in the $199 or less bracket. In fact, some of the low cost Intel/Android solutions out there currently from the likes of Acer, Dell, Asus, and Lenovo, all compete performance-wise pretty well versus the current generation of mainstream ARM-based Android tablets.
I'm really waiting for an x86 phone that can be bought in the USA. These have been available for years in India (!!!!), its really appalling that you cannot yet buy one in the US of all places.
Can someone recommend an inexpensive tablet for beginning Android development?
Power VR is terrible, Intel released a ton of low end Atom powered devices with Power VR GPU, but due to licencing agreements never released drivers except for the 32 bit variant of Windows 7 and never for Win 8 or Linux drivers worth a damn. Means Linux users were SOL when they tried using these machines for anything media related. And I doubt the situation with Power VR is going to be any better this time around. Avoid like the plauge any Intel hardware that's hard wired to a Power VR chip.
moox. for a new generation.
> ARM virtualizing x86 would be amusingly fast, too--faster than x86 running x86.
Are you joking or just high or low quality drugs? If what you are saying is true then how come Macbook Pros are shipping with Intel CPUs?
Um, no, x86 CPUs are nothing like ARM and I'm not aware of any commercial x86 CPU with an ARM backend. Yes, modern x86 cores use a RISC-ish microcode backend with an x86 decoder frontend, but that doesn't say anything in favor of ARM. All it means is that the industry has collectively agreed that CISC as a microarchitecture is a stupid idea - not necessarily as an instruction set.
I'm not a fan of x86 myself, and I think it's a stupid design with a vast amount of baggage causing a significant power/performance impact when designing an x86 CPU (that Intel can get away with because they're a generation or two ahead of everyone else in silicon tech), but then again ARM isn't the pinnacle of RISC either (though I do think it's better than x86).
Me, I'll take whatever microarch gets the best performance per watt at whatever TDP is relevant. If Intel can pull that off with x86-64, by all means. If ARM AArch64 ends up ahead, awesome. If both are about equal, I'll take whatever's more practical based on other factors.
*digs up the carcass you can flog the dead horse again*
No x86 chip from the last 20 years runs CISC instructions internally, it's split into micro-ops and AMD/Intel has spent the last 20 years optimizing their decoder and internal instruction set for this one task. If you think using the ARM instruction set is more optimized than that you've drunk way too much of the kool-aid.
Live today, because you never know what tomorrow brings
The cisc architecture is bad because it doesn't let compilers do good register allocation. Doesn't matter what your micro-architecture looks like if you can't reasonably put things in register. Which is why AMD64 has more registers.
"First they came for the slanderers and i said nothing."
The biggest problem for Intel in the mobile space is they don't really know how to make radio hardware. Qualcomm and TI are kicking their trash as far as that is concerned.
But their emulation technology is really impressive.
"First they came for the slanderers and i said nothing."
It was, at the time, largely speculated to be a marketing ploy to make MACs seem more like friendly PCs than as some weird PowerPC chipset that you play with in primary school. I speculate that virtualization has something to do with it, as it's easier and was more familiar at the time than JIT translation CPU-to-CPU (as LLVM does), and was interesting to the common man to run Windows upon a Mac.
Support my political activism on Patreon.
You mean from the last 12 years. Come on now, we know this started post-Pentium 4.
Support my political activism on Patreon.
No. Micro-ops were introduced in the Pentium Pro, first released 19 years ago.
I am becoming gerund, destroyer of verbs.
I couldn't care less what processor is in my phone or tablet. I only care if my phone or tablet can do what I want it to do. I suspect that I'm in the majority here. So, Intel, please explain to me why it matters whether my devices contain ARM or x86 architecture?
Wow, you're just too ignorant. The Pentium Pro started doing this, came out in 1995 and was one of the fastest CPU on par with high end RISC. With that and the SMP support, it was an important step in the replacement of RISC workstations and servers by x86 PCs. A good Pentium III at 700MHz to 1GHz, with an architecture close to the Pentium Pro, still has performance comparable to a low end ARM (though it lacks multicore, H264 decoder etc.)
I don't know what you want your OS to do but I think we live in very different worlds.
Christ that's a complex architecture. How'd it do on power consumption? 0.01W?
Support my political activism on Patreon.
The cisc architecture is bad because it doesn't let compilers do good register allocation.
That's true, and it's also worth noting that all the complex addressing modes of CISC limit how many registers you can have. (Because you use bits for the addressing modes which could otherwise be used for register numbers.) So limited numbers of registers is not just a historical accident of CISC which can be easily fixed; for a given instruction size, a CISC design can address fewer registers than a RISC design.
But it's not even the whole story. Once you go superscalar and start dispatching multiple instructions per clock, it becomes really import to have fixed-length instructions, so that's another big problem with CISC.
which still imposes a significant overhead in terms of transistor count
They did it on the Pentium Pro which had ~1/1000th of the transistors modern processors have today. Even though the instruction set has grown a few times in size, it's certainly entirely irrelevant when it comes to total transistor count today. But keep on spouting nonsense.
Live today, because you never know what tomorrow brings
Actually, it matters on both fronts. It's why AMD64 simplifies the instruction path as well.
Variable length instructions are fairly compact, which saves I-cache. And I-cache uses much more transistors than the decoding logic. Even ARM has figured that out, because their Thumb-2 instructions are also variable length, and much more complex than ARM 32 bit instructions.
See the subject line.
On the other hand, on an architecture with a lot of registers, you waste bits to indicate the register numbers, even though in a lot of cases you only use a subset of the registers.
I think it's a stupid design with a vast amount of baggage
But the constant stream of incompatible architecture updates from ARM has a disadvantage too, combined with customer designed SoCs, every ARM design is pretty much different than any other, forcing developers to use a virtual machine architecture on top of it. How's that not a stupid design ?
As I understand it Intel is doing everything they can to make all the Google Play apps work on their Android implementation. How is that working out?
and let the hardware worry about keeping local stack access as fast as registers.
The reason for more architectural registers in x86-64 is that hardware has proven unable to do so. Or do you know something that Intel doesn't?
The Android Compatibility Definition Document (CDD), published by Google, requires the system to present a fixed-size window to applications. This "all maximized all the time" policy isn't the most helpful if you're trying to write one document while referring to another. How does it benefit the user if the calculator app, for example, takes the whole screen? X11/Linux, on the other hand, embraces multi-window paradigms in both tiled and floating forms.
Low-end ARM, that's Cortex-M0. I don't really think x86 will be ever able to compete in that application area. (Nor do I see why anyone should be trying to spread that mess further.)
Ezekiel 23:20
And they got rid of them anyway, haven't they?
Ezekiel 23:20
I am doing fine watching porn on Arm Android platform.
Obviously, if you went out to fetch you some Girl Android, you wouldn't need the arm.
Ezekiel 23:20
They did it on the Pentium Pro which had ~1/1000th of the transistors modern processors have today. Even though the instruction set has grown a few times in size, it's certainly entirely irrelevant when it comes to total transistor count today. But keep on spouting nonsense.
High-end Xeon, ~900 times as many transistors. Quad-core i7, only ~300. What makes you so certain that the instruction decode has not grown significantly in size since that first very minimal implementation on the Pentium Pro?
Instruction decode doesn't grow as fast as other things on the chip: interconnect, multiple issue execution units, added crypto accelleration, I/O, cache etc.. I know this because I design those chips.
More explicitly Pentium III perhaps has performance around Cortex A5 or A7..