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.
I just want to run OSx on a Surface Pro 2, that hardware specification is very similar to a Macbook Air, with the advantage of being cheaper, and pressure sensitive touch screen.
There are some solutions but closed hardware is the largest issue, no driver for the build-in WiFi. Same as for Android.
Example of Android, Windows, OSx, multiboot instructions:
http://www.insanelymac.com/forum/topic/292645-guide-surfacepro-1-2-osx-android-windows-multiboot/
http://www.tonymacx86.com/bat-cave/87345-osx-microsoft-surface-pro.html
Save the world. Stop using for real work power hungry under load ARM processors.
> 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
These are RISC cores--occasionally ARM or a modified architecture--running an x86 or x86-64 translation layer as the decode cycle, such that the x86 instructions are cached as RISC instructions. ARM virtualizing x86 would be amusingly fast, too--faster than x86 running x86.
I doubt ARM cores could execute x86 instructions faster then an Intel core. All Intel CPUs except for the ATOM does an x86/64 -> internal micro op (RISC like, could be an old RISC design but Intel will never disclose that to the public). AMD does has a license for ARM maybe that is where the next gen architecture for low power devices will become arm core + x86 instruction decoder.
Can't decide... clever trolling or actually stupid enough to believe what he wrote....
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.
PowerPC was lagging behind Intel big time.
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.
I am doing fine watching porn on Arm Android platform.
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.
And yet, they still have to deal with variable-length instructions, which means they still have to decode multiple possible instructions in parallel and throw some out, which still imposes a significant overhead in terms of transistor count. Intel won the CPU wars in spite of the x86 architecture, not because of it--they outdid everybody else on process.
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.
Many may not remember the old WinCE 1.x, 2.x, or 3.x days.
There were MIPS, SH4, and ARM devices and variants of the operating system...
The problem was that unless your app vendor made code for your device's CPU, you were pooched for using it. Hampered uptake for the longest time until most of the vendors opted for ARM exclusively.
This is the EXACT SAME SCHISM going on here.
For example, an app is a NDK boosted app. At least 1/3rd of the apps catalog is just that. Your App vendor will need to make an ARM *AND* an X86 build of their NDK components just for you to be able to use it on an X86 tablet or phone. That's VASTLY easier said than done for numerous reasons. Much of this whole discussion about X86 is to keep Intel relevant against the incursion of ARM into the server spaces that's about to happen. The *ONLY* selling point of X86 in an embedded context (which, technically, includes these Android devices...) is being able to run Windows or X86 Linux proprietary binaries you can't get on ARM or MIPS. Seriously.
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 was more that the PowerPC bunch couldn't get Jobs a suitable CPU that was compelling in the right timeframes. If it were just as you claimed, they'd not have done it- they spent QUITE a bit retooling to be able to run everything under X86 like they did.
Just goes to show you, many that speculate have their heads up their arses- because they were talking out their collective arses then...and that's how you end up doing that.
I can't see ARM virtualizing X86 any better than the other way around. X86 is a terrible execution architecture- that Intel and AMD have come up with all sorts of amazing tech to make the pig run fast. Stuff that consumes more power to do per clock. As such, you're going to have limited success even with dynrec capabilities (which is what Transmeta tried to do with X86...see where it got 'em...) in either direction, though you might have better luck doing X86 from ARM than the other way around.
Actually, it matters on both fronts. It's why AMD64 simplifies the instruction path as well.
Just let the compiler allocate memory on the stack, and let the hardware worry about keeping local stack access as fast as registers.
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.
Because this platform is optimized for doing this. Not some job related boring WinTel.
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.
A faster 1 watt amd/intel/via x86 desktop/laptop chip on 22nm/14nm would be an upgrade to the via 500MHz 'Eden ULV 500' processor:
http://tech.slashdot.org/story/07/08/24/0434259/via-unveils-1-watt-x86-cpu
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.
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?
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'm not going to touch anything with an intel cpu (intel is against freedom)
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.
I've been wondering when we would see a tablet/phone that includes ECC support. If your data is truly important, you want ECC. ECC doesn't need very much hardware (by today's standards) so I've been wondering if we'll ever see it on low-end devices.
More explicitly Pentium III perhaps has performance around Cortex A5 or A7..