Android On Intel x86 Tablet Performance Explored: Things Are Improving 97
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.
When an x86 Android Phone in the US (Score:3)
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.
Re:When an x86 Android Phone in the US (Score:4, Interesting)
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.
Well, are the current x86 phones Google Android or AOSP Android? In India the latter might sell fine as a smartphone, I think here in the western world we expect all the Google services (and tie-ins...)
Re: (Score:1)
The reason why is because Intel's modems haven't been certified yet for American operators.
Re: (Score:3)
Why? Why does it matter what CPU is in your phone if it runs the OS you want? I'm honestly curious. How does it materially affect you?
Re: (Score:2)
I'm really waiting for an x86 phone that can be bought in the USA.
Looks like your wish is coming true on Oct. 24: Intel Processors to Power New Asus Smartphone Hybrid for AT&T - TheStreet [thestreet.com]
Re: (Score:2)
I believe that's called a Blackberry 950. [wikipedia.org]
All snarking aside, though, I must ask: what is the attraction to an x86-based phone versus an ARM-based one?
Inexpensive tablet for Android development? (Score:2)
Re:Inexpensive tablet for Android development? (Score:4, Interesting)
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.
Re: (Score:2)
It is Google's official tablet development platform.
Interesting. Do you have a citation for that?
Re: (Score:2)
Google Nexus: http://en.wikipedia.org/wiki/G... [wikipedia.org]
I don't see where that says anything about it being Google's official tablet development platform.
Re:Inexpensive tablet for Android development? (Score:5, Informative)
Google has confirmed the older Nexus 7 is getting the update [arstechnica.com]. I actually just read this earlier today. I actually have the Nexus 7 (2012) so am looking forward to the update.
Re: (Score:2)
How inexpensive?
* $200 Nexus 7
* $299 nVidia Shield Tablet http://shield.nvidia.com/gamin... [nvidia.com]
* $350+ Nexus 10
Some tech specs comparisons ...
* http://gadgets.ndtv.com/nvidia... [ndtv.com]
* http://versus.com/en/nvidia-sh... [versus.com]
Power VR sucks (Score:5, Informative)
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.
Re: (Score:2)
Re:Power VR sucks (Score:5, Informative)
Re: (Score:2)
The reason Intel keeps using PowerVR in those mobile chips is because it's faster than Intel's own GPU while using less power.
Re: (Score:1)
Heh...if it were trash, you'd not see it being one of the primary GPUs for mobile devices.
The problem isn't PowerVR itself. It's proprietary drivers on their stuff not being available that's always been the problem. Else you'd probably be singing their praises like most do NVidia for the problem space.
Mods, lay down the damn crack pipe...this one's not "informative", nor is it even accurate. Proof:
Rockchip RX3168 uses SGX GPU [imgtec.com]
Apple uses SGX in their iPads... [anandtech.com]
Ingenic uses it with their MIPS Android SOC [eetimes.com]
Media [xbitlabs.com]
Re: (Score:1)
If you actually read the article you would see that the PowerVR GPU performs better than the Intel graphics
Once again proving ARM is awesome (Score:2)
> 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?
Re: (Score:2)
Re:Once again proving ARM is awesome (Score:5, Insightful)
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.
Re: (Score:3)
Re:Once again proving ARM is awesome (Score:4)
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.
Re: (Score:2)
Re: (Score:1)
Actually, it matters on both fronts. It's why AMD64 simplifies the instruction path as well.
Re: (Score:1)
Re: (Score:3)
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?
Re: (Score:2)
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 ?
Re: (Score:3)
*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.
Re: (Score:2)
Re: (Score:2)
No. Micro-ops were introduced in the Pentium Pro, first released 19 years ago.
Re: (Score:3)
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.)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
More explicitly Pentium III perhaps has performance around Cortex A5 or A7..
Re: (Score:1)
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.
Re: (Score:3)
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.
Re: (Score:1)
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?
Re: (Score:1)
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.
Re: (Score:2)
Re: (Score:2)
The biggest proble (Score:4, Informative)
But their emulation technology is really impressive.
Re: (Score:3)
Infineon (owned by Intel) is a pretty big player in the mobile market as well. And while it's true Intel doesn't do radios, they bought Infineon for that reason.
Of course, a lot of phones are using Qualcomm SoCs so naturally they want to use Qualcomm modems and bundle it together (along with an Qualcomm (Atheros) WiFi/Bluetooth chipset).
Re: (Score:2)
Infineon (owned by Intel) is a pretty big player in the mobile market as well. And while it's true Intel doesn't do radios, they bought Infineon for that reason.
That's true, I'm not sure why we haven't seen them integrated yet.
Re: (Score:2)
Re: (Score:2)
may be more difficult than it seems.
And it doesn't seem easy lol. That's a good point.
Re: (Score:2)
I don't know what you want your OS to do but I think we live in very different worlds.
Hey, dummy, Android IS Linux (Score:2)
See the subject line.
Re: (Score:1)
Yes, Android is Linux in the same sense that an ATM (which often run Win-embedded) is Windows, which is to say, way to completely miss the point so you can show off your pedantry skills while contributing absolutely nothing of pedagogical value.
Re: (Score:3)
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).
Re: (Score:1)
Supposedly you can install a full Linux distro alonside Android, accessible via VIM, but I could never get it to work and just gave up. I also never got SSH to work properly with an X-server on Android (not for the lack of trying).
As a last resort, I can always use Microsoft RD and VPN to Remote Control a Linux or Windows machine.
All maximized all the time (Score:2)
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.
Re: (Score:2)
Why should I care? (Score:2)
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?
Re: (Score:2)
Re: (Score:2)
I have no affiliation with Intel, but here's your answer: Most Android apps are written in DALVIK and, for those, it really doesn't matter. It does, however, matter for native C/C++ apps, or apps utilizing native C/C++ components; if there's only an ARM build for the app you use, you don't want an x86 CPU.
This is mostly an issue with games, since they're the apps that push the performance boundaries enough that it makes sense to write native code.
So a less-technical but almost as correct answer is: If you buy an Intel tablet some games won't run on it until the game developers get around to building for Intel. How long that takes depends in large part on how many Intel tablets are sold.
Re: (Score:2)
Depends on which classes of apps you're talking about there. There's more than just games that use NDK code. That stuff..you're screwed on unless the vendor gets around to making an X86 version.
This is Intel trying to stay relevant against ARM...which is encroaching on their server space. If Intel weren't pushing all the green blow around for the vendors to take up, subsidizing these things, you'd not see X86 devices in the Android space.
Re: (Score:2)
[Emulation slowdown due to the developer's refusal to recompile an ARM NDK app for x86] is mostly an issue with games, since they're the apps that push the performance boundaries enough that it makes sense to write native code.
I thought the Android NDK wasn't intended for performance [android.com] as much as for sharing the model [wikipedia.org] (application logic and data access) code with versions of the application made for other platforms. You don't want to have to write in C++ once and then rewrite it line-by-line by hand in Java for two reasons: hand translation is more likely to introduce bugs, and it doesn't pick up on changes made to the original version (the Don't Repeat Yourself principle).
Re: (Score:3)
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 prob
Re: (Score:2)
I thought the Android NDK wasn't intended for performance [android.com] as much as for sharing the model [wikipedia.org] (application logic and data access) code with versions of the application made for other platforms.
A quote from the URL you linked to:
Typical good candidates for the NDK are CPU-intensive workloads such as game engines, signal processing, physics simulation, and so on.
So, according to that page, the NDK is largely made available for performance.
Re: (Score:2)
Re: (Score:2)
The part of that page that confused me is right above what you quoted: "Notably, using native code on Android generally does not result in a noticable performance improvement."
Yeah, I agree that the page is confusing. It seems to contradict itself. My guess is they consider games a special case, or something.
A friend of mine does iPhone and Android development and his comment is that NDK is basically a requirement for any non-trivial games on Android.
Re: (Score:2)
Re: (Score:2)
Yes, this is a great point. I do care, but in the opposite way that Intel wants me to. Many of the apps I use are native, and all of the apps I write for Android are native. So, I doubt I will ever use an x86 based device. Unless there is some super-special advantage to what Intel is offering, the pain and impact of the change would be too much.
Re: (Score:2)
There are some apps that are Windows/Adroid only. In order to run them side-by-side, you need some form of virtualization. Blue Stacks, Andyroid, etc...
The trick though, is that the Android VMs for Windows require a CPU and BIOS that support virtualization. Which means to pull this off, you explicitly need to know what processor (and BIOS) is in your phone or tablet.
-Rick
Re: (Score:2)
Its all about that sweet sweet binary compatibility ... with windows 3.11
Re: (Score:2)
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.
What about app compatibility? (Score:1)
Re: (Score:2)