The Google Nexus 9 Review
by Joshua Ho & Ryan Smith on February 4, 2015 8:00 AM EST- Posted in
- Tablets
- HTC
- Project Denver
- Android
- Mobile
- NVIDIA
- Nexus 9
- Lollipop
- Android 5.0
GPU Performance
While Denver is new, the Kepler GPU in the Tegra K1 is mostly a known quantity by now. In the Nexus 9, the GPU is still a single SMX clocked to 852 MHz. In order to verify performance, we turn to our standard test suite. For the most part, our GPU-bound tests are meant to represent gaming performance although tests like 3DMark can have CPU-bound aspects while GFXBench tends towards being a pure GPU test.
The Nexus 9's GPU has effectively identical performance to what we saw in the SHIELD Tablet, which means that the Nexus 9 should be able to support a broad range of games without performance issues. There is a bit of a noticeable performance delta when comparing on-screen performance, but this is simply due to the higher resolution of the Nexus 9's display. The one notable exception is the 3DMark physics test, which seems to scale with core count quite well, and that causes Denver to fall slightly short of the quad A15 configuration.
NAND Performance
While storage performance can often be secondary to a smooth user experience, poor storage performance is extremely painful. This is similar to RAM, where the difference between 2 and 3 GB is generally academic, while the difference between 512MB and 1 GB is enormous. While there have been some issues with Androbench with the move to Android 5.0, it seems that the timer issues have since been resolved, so it's possible to resume using the results from Androbench to get a rough idea of NAND performance.
Here the Nexus 9 doesn't suffer nearly as much from full disk encryption that is forcibly enabled on the device; performance is noticeably higher than what we see in the Nexus 6. This seems to lend some credence to the theory that CPUs with ARM v8 ISA would be better suited to handling the need to encrypt and decrypt storage in real time. I tested the Nexus 9 with a custom kernel without full disk encryption to see how Androbench scores might change, but this didn't have a noticeable impact which seems to back this theory, although I'm still not confident that FDE is a good idea to enforce across all new devices.
The NAND itself, a Samsung eMMC package designated by the name BWBC3R, seems to be quite performant outside of pure sequential access, which seems to suggest that HTC hasn't skimped out in this area at all, and the use of F2FS is responsible for some of the best random I/O scores in any mobile devices we've tested thus far.
Facebook
Twitter
RSS
169 Comments
View All Comments
dtgoodwin - Wednesday, February 4, 2015 - link
I really appreciate the depth that this article has, however, I wonder if it would have been better to separate the in depth CPU analysis for a separate article. I will probably never remember to come back to the Nexus 9 review if I want to remember a specific detail about that CPU.nevertell - Wednesday, February 4, 2015 - link
Has nVidia exposed that they would provide a static version of the DCO so that app developers would be able to optimize their binaries at compile time ? Or do these optimizations rely on the program state when they are being executed ? From a pure academic point of view, it would be interesting to see the overhead introduced by the DCO when comparing previously optimized code without the DCO running and running the SoC as was intended.Impulses - Wednesday, February 4, 2015 - link
Nice in depth review as always, came a little late for me (I purchased one to gift it, which I ironically haven't done since the birthday is this month) but didn't really change much as far as my decision so it's all good...I think the last remark nails it, had the price point being just a little lower most of the minor QC issues wouldn't have been blown up...
I don't know if $300 for 16GB was feasible (pretty much the price point of the smaller Shield), but $350 certainly was and Amazon was selling it for that much all thru Nov-Dec which is bizarre since Google never discounted it themselves.
I think they should've just done a single $350-400 32GB SKU, saved themselves a lot of trouble and people would've applauded the move (and probably whined for a 64GB but you can't please everyone). Or a combo deal with the keyboard, which HTC was selling at 50% at one point anyway.
Impulses - Wednesday, February 4, 2015 - link
No keyboard review btw?JoshHo - Thursday, February 5, 2015 - link
We did not receive the keyboard folio for review.treecats - Wednesday, February 4, 2015 - link
Where is the comparison to NEXUS 10????Maybe because Nexus 10's battery life is crap after 1 year of use!!!
Please come back review it again when you used it for a year.
treecats - Wednesday, February 4, 2015 - link
My previously holds true for all the Nexus device line I own.I had Nexus 4,
currently have Nexus 5, and Nexus 10. All the Nexus devices I own have bad battery life after 1 year of use.
Google, fix the battery problem.
blzd - Friday, February 6, 2015 - link
That tells me you are mistreating your batteries. You think it's coincidence that it's happening to all your devices? Do you know how easy it is for batteries to degrade when over heating? Do you know every battery is rated for a certain number of charges only?Mostly you want to avoid heat, especially while charging. Gaming while charging? That's killing the battery. GPS navigation while charging? Again, degrading the battery.
Each time you discharge and charge the battery you are using one of it's charge cycles. So if you use the device a lot and charge it multiple times a day you will notice degradation after a year. This is not unique to Google devices.
grave00 - Sunday, February 8, 2015 - link
I don't think you have the latest info on how battery charging vs battery life works.hstewartanand - Wednesday, February 4, 2015 - link
Even though I personal have 6 tablets ( 2 iPads, 2 Windows 8.1 and 2 android ) and as developer I find them technically inferior to Actual PC - except for Windows 8.1 Surface Pro.I recently purchase an Lenovo y50 with i7 4700 - because I desired AVX 2 video processing. To me ARM based platforms will never replace PC devices for certain applications - like Video processing and 3d graphics work.
I am big fan of Nvidia GPU's but don't care much for ARM cpus - I do like the completion that it given to Intel to produce low power CPU's for this market
What I really like to see is a true technical bench mark that compare the true power of cpus from ARM and Intel and rank them. This includes using extended instructions like AVX 2 on Intel cpus.
Compared this with equivalent configured Nvidia GPU on Intel CPU - and I would say ARM has a very long way to go.
But a lot depends on what you doing with the device. I am currently typing this on a 4+ year old Macbook Air - because it easy to do it and convenient. My other Windows 8.1 ( Lenovo 2 Mix 8 - Intel Adam Baytrail ) has roughly the same speed - but Macbook AIR is more convenient. My primary tablet is the Apple Mini with Retina screen, it is also convent for email and amazon and small stuff.
The problem with some of bench marks - is that they maybe optimized for one platform more than another and dependent on OS components which may very between OS environments. So ideal the tests need to native compile for cpu / gpu combination and take advantage of hardware. I don't believe such a benchmark exists. Probably the best way to do this get developers interested in platforms to come up with contest for best score and have code open source - so no cheating. It would be interesting to see ranking of machines from tablets, phones, laptop and even high performance xeon machines. I also have an 8+ Year old dual Xeon 5160 Nvidia GTX 640 (best I can get on this old machine ) and I would bet it will blow away any of this ARM based tablets. Performance wise it a little less but close to my Lenovo y50 - if not doing VIDEO processing because of AVX 2 is such significant improvement.
In summary it really hard to compare performance of ARM vs Intel machines. But this review had some technical information that brought me back to my older days when writing assembly code on OS - PC-MOS/386