First Quad-Core Android Tablet Reviewed 218
adeelarshad82 writes "The Asus Eee Pad Transformer Prime happens to the first Quad-Core Android Tablet, which also makes it the fastest and most powerful tablet. The secret ingredient is Nvidia's five-core Tegra 3 chipset, including four cores which work together at up to 1.4GHz each and a 'companion core' which runs alone. When tested on the Antutu system benchmark, the Prime scored a breathtaking 10,619, which is roughly double the score of even fast devices like the HTC Jetstream. Benchmark results for Sunspider and Browsermark browsing scored at 17ms and 98324, respectively, which also happened to be amongst the best. The tablet weighs 1.3 pounds and measures 10.4 by 7.1 inches, but it's very slim at 0.3 inches."
Re:Touch lag (Score:5, Informative)
Re:Tegra (Score:5, Informative)
Re:What you don't see (Score:4, Informative)
Re:Touch lag (Score:5, Informative)
Re:why (Score:5, Informative)
For at least the past 5 years, processing performance in almost all envelopes has been limited by power consumption and/or heat (which are two sides of the same coin).
Your i3 has a 35W TDP, this CPU looks like perhaps 2-4W TDP. So yours is 3.9x the speed while using 8.8x the power. Targeting a lower performance tends to allow for better efficiency, and so does having more cores/threads to do the work. This is largely because structures in a core that improve single threaded performance have diminishing returns for the amount of power they consume (caches, out of order execution instruction windows, buffers, wide superscalar execution, etc). So you can't necessarily say the Tegra 3 is a better device than the i3, but neither can you say the i3 is better (you really need to compare the same power or performance).
Re:Touch lag (Score:5, Informative)
Multi-core isn't going to help basic UI issues, those will all be running on a single core. The problem is Android isn't really written to be efficient. XML based UIs running in Java (with garbage collection occurring who knows when), a codebase that's frequently convoluted and an architecture that sometimes looks like someone took the Gang of Four book and tried to use every pattern at once. I mean seriously, why does setting a selection on a text view require a selection class rather than a start and end index in the widget?
If you want to fix it, you need a complete overhaul of the framework and quite likely rewrite chunks of it in C or C++.
Re:Other end of the spectrum (Score:5, Informative)
Ice Cream Sandwich fixes this, but also has hardware requirements that mean very few existing devices will be supported
Google has stated that pretty much every device that can run Gingerbread (50% of all Android devices out there run Gingerbread) can run Ice Cream Sandwich.
Re:Touch lag (Score:3, Informative)
I have ZTE Blade what I would say is slowest and cheapest (about 120 dollars without contract) Android phone on the market.
ARM6 254-600Mhz
512 RAM
512 NAND Flash
800 x 600px Super bright LCD
And I have MicroSD Class 4 in it.
I have had Android 2.1, 2.2, 2.3 (current 2.3.7) on it and coming is 4.0 for it (there is almost everything working)
The 2.1 had very little laggy home screen. What was fixed with ADW launcher.
But a 2.2 fixed everything and phone was smooth and without lags in use.
And a 2.3 was not different (thanks CM7. 2.1 and 2.2 were officials for now).
But the problems of ARM6 600Mhz processing speed are visible when using heavy CPU demanded apps.
Like when starting a such application, it might take 1-2 seconds instead instantly like how normal Android apps starts.
Webpages scrolls smoothly, haven't come up with any what would laggy, thanks to non-existing Flash for the ARM6 architecture.
The phone is as well fine when using it as hotspot and traffic is to HSDPA network a full 7.2Mbits. It does get little warm in long run because WLAN chip (12h) but nothing serious.
But yes, I am little jelous for other Android phone owners like Samsung Galaxy S II. As I would like to have bigger screen, bigger battery (SII with 3500mAh battery is.... dream) and little more responsive phone when starting those heavy applications. As I want to use Autodesk applications or some very intensive 3D modeling applications what demand a better GPU.
I bought a cheap Android phone and didn't expect a much. But it was very huge supprise when noticing how perfectly it runs.
So, I got hungry and I want more. Maybe in a year I bougth a something cheaper from 200-300 dollar range what offers more speed and features what are today available in highend phones.
Re:Other end of the spectrum (Score:3, Informative)
http://www.youtube.com/watch?v=gVleFJuNuQI [youtube.com]
That is basicly work what CM developers did under a week from Android 4.0 source release.
ZTE Blade has ARM6 600Mhz, 512 RAM, 512 NAND Flash.
The Android 4.0 SDK was not available for ARM6 but for least ARM7. So they needed to compile it as well (one developer compiled it with netbook in 31 hours).
Since then, GPU drivers has been added and OpenGL is coming shape so smoother UI can be excepted. Still needs optimizing but most features are there.
If almost slowest currenty available Android phone can run ICS, then definetely most of the mid-range androids can.
Chipset? (Score:5, Informative)
The secret ingredient is Nvidia's five-core Tegra 3 chipset
You really think these compact machines use sets of chips? Quite the opposite. They're systems on a chip [wikipedia.org] (SoC), often even a package on a package [wikipedia.org] (PoP) i.e multiple chips layered into one package. Now, don't get smart and point out that technically a PoP is a chipset - they're used for packing an SoC with DRAM and flash memory. The multiple functions of a chipset (e.g peripheral interfaces) are all on the one chip of the SoC.
Re:Touch lag (Score:2, Informative)
From user experience POW, losing a few hundred cycles every 1000 cycles would usualy be quite acceptable, but the problem with many GC's is that they tend to use few hundred million cycles every ten billion cycles which is quite noticeable even though it's in fact a smaller proportion of the total time.
Re:Touch lag (Score:4, Informative)
No, the reason Android isn't as fluid as iOS is that it multi-tasks. When you run an iOS app stuff like screen transitions get absolute priority over everything else. The app is basically frozen while the screen transitions in order to make it look slick. Android apps are not tied to the UI in the same way so sometimes if you have a lot going on or if the OS needs to free up some RAM the transition effects might suffer a bit.
Having said that they are really smooth on my Galaxy S. I don't have them all turned on because they waste time, much like the pointless window minimise/maximise animations in Windows or MacOS. Personally I prefer to have multi-tasking and more features at the expense of a slightly less slick GUI. iOS has the advantage of being design for a very limited number of specific models and thus can optimise for them, while Android has to be more generic. Again I personally prefer to have that freedom to chose devices from any vendor rather than being locked in to Apple.
The Android API is nice and the GUI stuff scales nicely, plus Java apps are not tied to any particular CPU architecture so will automatically make use of new features such as the Neon instructions on ARM7 or SSE if Intel ever get x86 based tablets/phones shipping. iOS uses managed code too, which has similar overheads in terms of garbage collection and JIT compilation as Google's JVM implementation. You can also write native Android apps if you want to.
Re:Touch lag (Score:5, Informative)
Re:The original Tranformer is great (Score:2, Informative)
Re:Tegra (Score:5, Informative)
That is quite impressive when you consider that the Transformer has extra peripherals to run such as the SD card. The screen is also higher resolution (more graphics load), it multitasks, performs better and costs less.
There is nothing magical about Apple hardware.
Re:Other end of the spectrum (Score:5, Informative)
Android was historically developed without any GPU acceleration requirements, and the OS up through Honeycomb still does most UI drawing on the CPU instead.
Absolute rubbish. Android's UI is rendered with OpenGL ES and thus fully hardware accelerated. It has been since day one, it is just that most cheap phones have slow GPUs with old drivers and little graphics RAM. OpenGL ES support is mandatory for Android devices, but of course low end chipsets use software rendering to make up for lack of hardware support. Even if the hardware supports basic operations like blitting images older chips don't support DMA so the CPU has to manually copy the image into graphics RAM first.
Bad touch input is usually down to the update rate of the touch controller (the cheap ones only manage about 12 updates per second) and phones lagging because they have crappy manufacturer supplied UI mods. You can see this easily by comparing older HTC phones running the stock firmware and Cyanogen. The stock firmware has the HTC Sense UI that slows everything down and make the touch screen unresponsive, but load up Cyanogen and set the UI to use 16 bit textures for lists and menus (to conserve graphics RAM) and it will fly along.
People seem to expect iPhone like performance from Android devices cost 1/5th as much. My Galaxy S with all effects turned on is just as slick as an iPhone, more so in fact because it supports live wallpapers.
Re:Tegra (Score:4, Informative)