Slashdot Mirror
Nexus 5 With Android 4.4 and Snapdragon 800 Challenges Apple A7 In Benchmarks
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.
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.
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...
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.
Are agnostics skeptical of unicorns too?
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.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
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.
The smooth scrolling on the iPhone is implemented by the scroll view instructing every view inside one to draw a larger region than is actually composited into the final image. It looks smoother because it's just compositing already-drawn data into the exposed region, rather than having to do all of the rendering on demand. It's a pretty neat trick, but this trick comes at the expense of making the CPU do more work to render bits of a page that may never be seen, and used-CPU means used battery life. I don't know what the total cost is, but Apple has obviously decided that it's worth it and you apparently agree, but it's not a question of CPU speed it's a question of what the widget set does with it.
I am TheRaven on Soylent News
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
Bogtha Bogtha Bogtha