The Nexus 4 is based around a 1.5 GHz Qualcomm Snapdragon S4 Pro SoC, the quad core Krait APQ8064 with Adreno 320 GPU, which is still built on a 28nm process. The combination of APQ8064 for AP and MDM9x15 for baseband is Qualcomm's Fusion 3 platform, and the Nexus 4 and Optimus G are the first phones to market based on that platform. This is a relatively unique opportunity for Nexus, which until recently wasn't really first to market with the latest and greatest silicon. 

A while ago we posted our Nexus 4 and Nexus 10 performance preview. At that point we still had a lot of testing to perform, and many people noted that the Nexus 4 performance was far behind the LG Optimus G despite it being based on the same platform. Later, some people noticed that I had uploaded another set of results from GLBenchmark 2.5 to the online result browser with much better performance. The difference wasn't some over the air software update but rather that I was running some of the tests with the Nexus 4 in a ziplock bag inside the freezer to mitigate any condensation problems, and simultaneously nail down any possible thermal throttling. 

I've re-run everything and can confirm obviously that there was thermal throttling going on affecting some of the results, and have included the new results wherever there was a deviation from previous. For those wondering why the LG Optimus G wasn't affected in spite of it having the same platform, the reason is because the results from the Optimus G were run in parts due to some instability affecting its ability to run a complete set of tests without crashing. The Nexus 4 has newer drivers that don't crash during a full GLBenchmark 2.5 run but as a result run the device long enough for thermal throttling to kick in. 

GLBenchmark 2.5 - Fill Test

GLBenchmark 2.5 - Fill Test (Offscreen 1080p)

GLBenchmark 2.5 - Triangle Texture Test

GLBenchmark 2.5 - Triangle Texture Test (Offscreen 1080p)

GLBenchmark 2.5 - Triangle Texture Test - Fragment Lit

GLBenchmark 2.5 - Triangle Texture Test - Fragment Lit (Offscreen 1080p)

GLBenchmark 2.5 - Triangle Texture Test - Vertex Lit

GLBenchmark 2.5 - Triangle Texture Test - Vertex Lit (Offscreen 1080p)

GLBenchmark 2.5 - Egypt HD

GLBenchmark 2.5 - Egypt HD (Offscreen 1080p)

GLBenchmark 2.5 - Egypt Classic

GLBenchmark 2.5 - Egypt Classic (Offscreen 1080p)

The result of the tests in the freezer results that are much closer to what we'd expect based on the APQ8064 MDP/T runs and the Optimus G numbers I saw in Korea. 

When it comes to the CPU side of things there were results also affected by thermal throttling. I spaced some of those runs out (unintentionally) enough that performance didn't change, but for other things it did affect performance. I can't tell what GPU clocks end up being when the SoC decides to throttle, but it is possible to nail down what CPU performance state APQ8064 settles down into when there's throttling going on by looking at the state tables. 

 
Left - 1.134 GHz during throttling (running tests), Right - All the performance states

I can see the Nexus 4 not use any of the performance states above 1134 MHz when it's getting hot, as shown in the images above. I've tweeted a link to the pastebin for thermald.conf which I believe configures the thermal cutoffs and will be interesting to kernel hackers trying to play with these values. 

SunSpider Javascript Benchmark 0.9.1 - Stock Browser

BrowserMark

Google Octane Benchmark v1

Mozilla Kraken Benchmark

Vellamo Benchmark - 2.0

Vellamo Benchmark - 2.0

Sequential Read (256KB) Performance

Sequential Write (256KB) Performance

Random Read (4KB) Performance

Random Write (4KB) Performance

Our CPU performance side is unfortunately still dominated by JavaScript performance tests. The story there is that the Nexus 4 ships with Chrome (and originally shipped with a newer build of Chrome than what was on the market - we were running that updated version all along) and thus the mainline version of the V8 JavaScript engine. OEMs perform their own optimizations to the V8 library, and try to upstream whatever they can into the main project, but in the case of Chrome for Android that means V8 sans secret OEM sauce. 

Battery Life and Charging Android 4.2 - New Flavor of Jellybean
Comments Locked

188 Comments

View All Comments

  • zeroidea - Wednesday, November 14, 2012 - link

    It's Tucson, AZ!

    They must have been taken a few weeks ago (a lot of the streetcar construction downtown has been completed)
  • DukeN - Tuesday, November 13, 2012 - link

    Brian, are you able to verify if the material is actually rubber? This would be a serious issue for many users, including some in my family with severe latex allergies.
  • PeteH - Tuesday, November 13, 2012 - link

    Wow, that didn't even occur to me, but it could be a real problem. It's not like latex is an uncommon allergy either, so hopefully Google or LG thought about that and used something other than rubber.
  • Rits - Tuesday, November 13, 2012 - link

    Its rubberised plastic. Shouldn't be a problem at all to latex-allergic folks.
  • PeteH - Tuesday, November 13, 2012 - link

    Not doubting you, but do you have a source?
  • Rits - Tuesday, November 13, 2012 - link

    Previous LG devices that had the same material were latex-free. There is no reason this one would deviate. But, you could always email LG/Google for an official confirmation.
  • MadMan007 - Tuesday, November 13, 2012 - link

    Should have used a dual core CPU with a decent GPU. Quad core is a waste in phones because overall it hurts battery life more than it helps certain usage models, and if there's so much throttling what's the point.

    Does Android do thread parking? Do these CPUs have per-core power gating?
  • JohnnyL53 - Tuesday, November 13, 2012 - link

    Throttling may not be an issue in the real world in terms of a noticeable affect and may just show up in benchmarks. In other words, who cares what the benchmark performance is if its at such a high level it's not perceptible? What I never see explained is how far apart do you need to get before you can distinguish one device's performance from another. Granted on most of the tests the iPhone far outpaces any other phone, but is it even noticeable? Are we just talking bragging rights, future proofing, etc?
  • name99 - Tuesday, November 13, 2012 - link

    The value of a faster CPU on a phone, for normal people, right now, is that the phone feels snappier. So, for example, an iPhone5 feels perceptibly faster than an iPhone 4S not because computational tasks take 1 minute instead of 2 minutes, but because a dozen small things take .1 second instead of .2 seconds.

    From this point of view
    (a) thermal throttling is no big deal, and I personally have no problem with it. It was a good idea when Intel started it years ago (to the accompaniment of a massive chorus of whining) and it would be a fine idea to have it as built into an ever wider selection of phone chips.

    (b) quad-core remains a solution in search of a problem. Maybe one day it will have value; maybe it has value for games (which I don't care about). But for the way I and my crowd use phones, it has no value yet.

    (c) the present collection of benchmarks are largely useless because they do NOT track this essence of snappiness which is what most people mean when they say a phone is "fast". Yes, if you're a developer writing demanding code you care about very particular aspects of the phone --- perhaps you care about the memory bandwidth, or the FLOPs, or the random flash write performance. But for most people, what matters is the snappiness. Existing benchmarks are a poor proxy for that feeling, and I do wish the serious blogs could do better.

    Right now all we have is this lame sniping like 12 yr olds: "My Nokia feels fast", "Oh yeah, well my Samsung feels even faster", "Well my iPhone feels fastest of all". And regardless of your feelings about Apple, if you support Team Android or Team Windows, you should be pushing for snappiness benchmarks because that is one of Apple's great strengths --- they don't care about, and don't optimize for benchmark numbers, they optimize for snappiness, and buyers do appear to be aware of and notice this. As long as the non-Apple market is forced to compete on these "overt" benchmarks as ways for each vendor to differentiate themselves and show their technical superiority, what will be optimized for are benchmark numbers, NOT user feel and snappiness.
  • Zink - Tuesday, November 13, 2012 - link

    I think with a DSLR at 60 FPS and editing to synchronize individually recorded videos it would be possible to do accurate side by side comparison of app responsiveness and web page loads. With a bit of video analysis, graphs could be made comparing performance down to the frame and FPS in animations measured.

    You could even do this on the go for a real world performance comparison. A normal day of use could be simulated by walking/commuting around your city and setting up a tripod in an apartment, on the sidewalk, inside an office building, at the bar etc. Then run several tests on each phone where you get the phone out of your pocket like normal and open a web page, post a comment, take a photo etc. all while the screen is on camera. Several similar tasks could be averaged into a single category score for a bit better repeatability.

    With proper analysis of the resulting video a pretty damn accurate comparison of the whole cellular, hardware and software system could be made. Basically the ultimate benchmark measuring user phone performance. I've seen some well done side by side comparisons but never in depth or with good numbers along with the video.

Log in

Don't have an account? Sign up now