Nexus 5 With Android 4.4 and Snapdragon 800 Challenges Apple A7 In Benchmarks 310
MojoKid writes "One of the hallmark features of Google's Nexus 5 flagship smartphone by LG isn't its bodaciously big 5-inch HD display, its 8MP camera, or its "OK Google" voice commands. That has all been done before. What does stand out about the Nexus 5 is Google's new Android 4.4 Kit Kat OS and LG's SoC (System on Chip) processor of choice, namely Qualcomm's Snapdragon 800 quad-core. Qualcomm is known for licensing ARM core technology and making it their own; and Qualcomm's latest Krait 400 quad-core along with the Adreno 330 GPU that comprise the Snapdragon 800, is a powerful beast. Google also has taken the scalpel to Kit Kat in all the right places, whittling down the overall footprint of the OS, so it's more efficient on lower-end devices and also offers faster multitasking. Specifically memory usage has been optimized in a number of areas. Couple these OS tweaks with Qualcomm's Snapdragon 800 and you end up with a smartphone that hugs the corners and lights 'em up on the straights. Putting the Nexus 5 through its paces, it turns out preliminary figures are promising. In fact, the Nexus 5 actually was able to surpass the iPhone 5s with Apple's 64-bit A7 processor in a few tests and goes toe to toe with it in gaming and graphics." Ars Technica has a similarly positive view of the hardware aspects of the phone, dinging it slightly for its camera but otherwise finding little to fault.
Re:New phone almost as fast as month old phone (Score:5, Informative)
New phone almost as fast as month old phone.
Xperia Z1 was released same day as iPhone 5s. It is faster, waterproof, and has higher res 1080 screen. It also has a 20.7MP camera with a much larger 1/2.3" sensor.
Re:New phone almost as fast as month old phone (Score:5, Informative)
the article doesn't touch on this, but I wonder how much untapped power is in that 64bit processor in iPhone. what's cool is, that's dormant in my phone right now, but will be unleashed next year so it will be like getting a new phone.
Please tell me you're being sarcastic... Even if all your apps get recompiled to 64-bit versions, you are not going to get a massive performance boost. Have you ever tried running a 32 vs. 64 bit install of Windows or Linux on the same hardware? Not too much difference for average use cases...
Implementation is real weakling (Score:3, Informative)
iPhone 5 got its ass handed to it due to the weak CPU in it.
Weak CPU, or weak physics engine that didn't use OpenCL or the Accelerate framework...
In fact the benchmark technical guide [amazonaws.com] says explicitly:
The GPU load is kept as low as possible to ensure that only the CPUâ(TM)s capabilities are stressed.
Which is a really stupid way to compare things as anything that relied on advanced physics would be using some kind of accelerator for computation other than the CPU. It also means it's not using any of the real-world physics engines a game would be using.
Sure the iPhone Physics score will be down a lot if you tie both hands behind its back and throw it in a river.
Re: Keep In Mind (Score:1, Informative)
http://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-you.html
Re:This is not a fair comparison (Score:4, Informative)
Portable to what exactly?
Computers for starters.. Long term, we can run Android apps on Intel computers at full speed. On Apple, that won't be possible without an emulator, recompile, or switching the computer to ARM.
Ah yes, the classic Fandroid response of "Just around the corner it's gonna get better!!!"
Apple's program execution is nothing special. ART eliminates the disadvantages of using portable code, and allows the execution system to be far more flexible than Apple's. Android is using a slower system at the moment, but, better solutions do take more effort (one giant leap for mankind).
99% of Android users don't install other ROMs on their phone.
Where'd you get that figure? Anyone who purchased the humble bundles did. Part of the Apple Store's intention is to actively block competitors. That is even dodgier when you consider that Apple has stolen products in the past (which, after doing so, they will be competing against you). Also, if the hacker community wasn't there, we would have no good way to make videos of the product we developed for iPhone (we tried a video camera, it was terrible).
That to get any visibility you have to go through Google Play which has many the same terms as the Apple App Store.
Humble bundle gets plenty of visibility, and its a separate system. Also,if you spend 2 months developing software, you WILL be able to run it on the platform ultimately. On the Apple App store, you basically need to discard or Cydia the software if it isn't approved.
Finally, in 2009, it was estimated that Cydia was installed by 10% of the iPhone userbase (could be biased, from the Cydia website). And so, their app's obviously do have PLENTY of visibility on iPhone. The fact though that Cydia constantly breaks though is "hostile" towards unapproved apps. It shouldn't be necessary.
You can't afford $99? For any decent programmer that's not even 3 hours of pay.
That's $99 without any guarantee you will ever be able to sell the software you are developing on another iPhone (unless you go to Cydia). That sounds fantastic! There are so many developers on Cydia, who have developed great Apps, that Apple has screwed. I'm sure many Cydia developers LOVE Apple as much as you do.
Then maybe they should have gotten their phone replaced or put it in a case? How is it Apple's fault that someone drops their phone and is dumb enough to cut themselves on the glass?
Why is it an airplane's company fault if a pilot accidentally hits the wrong button causing the plane to crash? In the Airplane industry, they call this "Human Factors". The glass backing is an inexcusably poor design. The guy who I saw was cut, was just picking up his dropped phone . Basically, if you drop it on its back, it is designed to shatter, and if you are lucky, there are sharp glass fragments on the ground for other people to step on. Apple must have known that making the back out of glass (instead of Plastic or other materials), but instead, they decided to use an extremely fragile material (obviously weighing up whether the Apple Fanbase would care or not), and they ignored human factors in the process of designing the phone (all for the interest of making a good looking phone).
Re:This is not a fair comparison (Score:5, Informative)
Actually, if you look at the benchmarks it loses in everything but the GL benchmarks. Then go and look at the benchmarks at phonearena and the 5S hands the Nexus 5 it's ass on pretty much every test. Personally I'll reserve final judgement until I see an anadtech comparison but looking at everything out there right now, the Nexus 5 doesn't hold a candle to the iPhone 5s. That's not to say it's a bad phone, because it isn't. I'm just saying you're buying a fantasy if you think this thing is on par with the 5S.
Before I get called an Apple fanboy, you should know that I own two phones and they are both Samsung Android phones.
Re: This is not a fair comparison (Score:1, Informative)
Predictably enough, battery life on the nexus 5 is a joke. Confirming the age old maxim - with sufficient thrust pigs fly just fine.
Re:This is not a fair comparison (Score:5, Informative)
And that fact is mostly irrelevant. Remember back when AMD started quoting their Athlon processors by speed rating rather than MHz because Intel went all out to get high clock speeds? I thought everyone knew that megahertz were not directly comparable between architectures these days.
In this case Apple has gone down the more complex route with a processor that can do more per clock cycle at the expense of added cost and power consumption. The Snapdragon CPU takes the opposite approach with simpler cores that run at higher clock rates. Such cores are cheaper to manufacture and have power consumption advantages when not running flat out at their maximum clock rate.
Also note that the benchmarks they ran don't saturate all four cores, and neither do most mobile games. The extra RAM helps the phone multitask, and no benchmarks or games use it all on either platform so it's meaningless.
It's pretty amusing that Apple spent so much time and money to develop their CPU and it ended up costing far more than the much simpler and equally fast competition. 64 bit turned out to be completely irrelevant at this stage.
Re:New phone almost as fast as month old phone (Score:5, Informative)
The main advantage of 64 bitness is access to a far larger memory address space. Yes there can be a few minor performance improvements with proper use of larger registers, but it's really not that big an advantage. Until smartphones and tablets start exceeding 4 gigabytes of RAM there is really not much point other than marketing to use 64 bit code on such devices.
That has been debunked again and again and again.
There has been iOS code that was measured to be 45% faster just by being recompiled to 64 bit. There are plenty of tricks in the Objective-C runtime and the C++ libraries that make it _significantly_ more efficient when running on a 64 bit processor. For example, a std::string up to 22 chars doesn't allocate any memory on the heap in 64 bit code but just uses three 64 bit words.
Re:This is not a fair comparison (Score:5, Informative)
Re:This is not a fair comparison (Score:5, Informative)
I'm not talking about the technical difficulty in writing a patch. I'm talking about the difficulty in applying a patch in practical terms. If I want to, say, modify my Xperia Pro so that a particular application that is useless to me isn't forcibly bundled, it's far more difficult than it should be.
I deal with people who commission apps on a regular basis. Unless the entire concept of an application is forbidden by Apple (e.g. porn), it's never been a deal breaker.
Which means nothing when vendors customise the implementations of those APIs and break them. It's all very well saying that, say, the API to draw a control on screen is the same across all devices, but if one device draws the control and another doesn't bother, that's kind of a problem.
I don't remember the full details, but the most egregious problem we had was that radio buttons simply weren't showing up on one device. At all. On another device, the rendering was completely fucked in some way, something like being a tenth of the size they should be or something. The code was right, and the application worked just fine on most of our test devices. But on some, they simply didn't work right due to vendor customisations.
Let's be straight here: I'm describing what Apple's policies mean for us in practice, and I'm reporting what clients actually ask us to do. You are scraping everything you can think of that Apple has ever rejected together. I'm sure there are lots of business plans that have fallen by the wayside in the five years Apple have been running the App Store. But that doesn't mean that they are a significant percentage of the apps people actually want to create.
No client has ever asked us to develop an alternative HTML rendering engine. Why would they? Besides, Apple don't have a problem with an alternative HTML rendering engine.
No client has ever asked us to set up their own app store. There are book stores on the App Store already, there's no rule against having a book/music/video store.
Alternative SMS messaging systems aren't against Apple's rules. I've got one on my phone right now.
No client has ever asked us to replace part of the system like a keyboard. If you have an application that needs a custom keyboard, you can implement one for your application, but you can't replace the keyboard in other people's applications.
When I say that the things clients ask us to do are things that are user-hostile, I'm talking about things like hookin
Re:New phone almost as fast as month old phone (Score:4, Informative)
The main advantage of 64 bitness is access to a far larger memory address space. Yes there can be a few minor performance improvements with proper use of larger registers, but it's really not that big an advantage. Until smartphones and tablets start exceeding 4 gigabytes of RAM there is really not much point other than marketing to use 64 bit code on such devices.
Oh c'mon. Slashdot is supposed to be the smart nerds.
One advantage of a 64 bit architecture (such as x86_64 or the A7) is that in order to hold 64 bit data. But if you're still working with 32 bit data (and most of us are), you can simply load each register with two 32 bit chunks, basically doubling the amount of data you can hold on chip, and the processor has functions to support this.
And if you look at what Apple did with the A7, not only does their 64 bit chip do this, but the new ARM64 specifications double the number of registers in general:
"The ARMv8-A instruction set doubles the number of registers of the A7 compared to the ARMv7 used in A6.[13] It now has 31 general purpose registers that are each 64-bits wide and 32 floating-point/NEON registers that are each 128-bits wide."
http://en.wikipedia.org/wiki/Apple_A7 [wikipedia.org]
So basically you now have an crazy amount of registers, and an insane amount of registers if you are dealing with 32 bit data still. The NEON registers are 128-bits wide and there are 32 of them. If you have 32 bit data, you can process 128 chunks at a time! If you're working in float_16 with NEON, you can work through 256 chunks at a time. That's crazy good compared to ARM32. That would really speed up anything that works with media, images, video, animations, etc, most of which a modern window server does.
But that's not really the end of optimizations. If your registers are large enough, why bother using pointers? And that's what Apple did with the Objective-C runtime on ARM64.
http://www.mikeash.com/pyblog/friday-qa-2012-07-27-lets-build-tagged-pointers.html [mikeash.com]
Basically, if you've got a small enough object type, like an object that holds an 32 bit type, you can skip the allocation of extra memory to hold this data, and just store it in the pointer itself. A lot of the low level and frequently hit methods in Obj-C (like the entire memory allocation tracking system) have been optimized for this, so you should see a speedup in even basic applications.
Re:This is not a fair comparison (Score:4, Informative)
I have lots of iPhone owning friends who switching to Android. Sometimes it was simply because they saw they could have the same functionality for half the price, or because they wanted a bigger screen, or just didn't like Apple's policies and software.
Anecdotes are worthless though, so let's look at the stats. Android is 80% of the market and on an upward trend. iOS is about 14% and falling. Source: https://en.wikipedia.org/wiki/File:World_Wide_Smartphone_Sales_Share.png [wikipedia.org]