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.
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.
You can pick up a used 2012 Nexus 7 tablet for $75 from a variety of locations, it will be getting the Android 5.0 update. It is Google's official tablet development platform.
moox. for a new generation.
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."
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.)
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.
Google has confirmed the older Nexus 7 is getting the update. I actually just read this earlier today. I actually have the Nexus 7 (2012) so am looking forward to the update.
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
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?
From the Google Play Store you can install a terminal emulator, an HTTP server, an SSH/SFTP server or client, bash, vim, gcc, make, git, mc, rsync...
Android supports standard keyboards and mice, and many devices have some sort of HDMI output (usually with an adapter).
There's a hidden treasure in Python 3.x: __prepare__()
You still get extra performance even if you don't want it. I'm not aware of any widespread execution environment for Java that would utilize SIMD code, and in addition to that, languages like C++ at least give you more control of your memory layout which is increasingly important for performance these days. Even if NDK isn't designed for performance, as long as the application runs native code compiled from a somewhat lower-level language like C, the app itself can be designed for performance.
What they probably mean by "NDK not designed for performance" is that the calls between the two environments are not as cheap as they could be if they tried harder. That's a different issue, now addressed in environments like LuaJIT 2 or Blink by making the JIT compilers aware of "foreign" code and allowing them to include the call-out sequences in the compilation and optimization process. In addition, the calls may be undesirable anyway if they involve a lot of data representation translation. What this means is that with NDK, you apparently won't get performance by, say, first writing your app in Java, profiling, and then porting a few data structures into C, because the call overhead would offset any performance increase. But that doesn't mean that if you write the whole thing in C and only call out when necessary (and perhaps offload just the interface to the Android code which should be cheap in general), the whole thing won't be faster - it most certainly will be.
Ezekiel 23:20