Slashdot Mirror
Early iPhone 6 Benchmark Results Show Only Modest Gains For A8
MojoKid writes: Historically speaking, we typically see impressive performance gains each time Apple releases a new custom processor for its mobile products. Certainly that was true of the A7 SoC, the world's first 64-bit smartphone processor. So, can we expect the same kind of performance bump from the iPhone 6 and iPhone 6 Plus, both of which sport the new custom A8 SoC? Maybe not. The iPhone 6 recently surfaced in results for the Basemark X benchmark and armed with a dual-core 1.4GHz Cyclone CPU and A8 GPU, the iPhone 6 scored 21,204.26 and a earned a place at the top of the chart, though not by much. By comparison, the iPhone 5s scored 20,253.80 in the same benchmark. In other words, the iPhone 6 is currently less than 5 percent faster than the iPhone 5s, at least as far as the Basemark X benchmark is concerned.
It's like 3D Mark, for iOS?
Something tells me Basemark X doesn't take advantage of any of the Apple specific APIs. We've been seeing a solid ~30-40% increase in FPS when using Metal over the iPhone 5S. Everything else feels about the same though, but then again I haven't had access to our test units for any extended length of time to actually benchmark stuff (they've been kept in a locked up room with no windows chained to an unmovable desk bolted into the floor for the past two weeks). The hardware definitely is faster, but it seems like one of those things that won't matter unless you're targeting iOS specifically and writing Apple proprietary code, so I kinda question how that is going to play out in the future (especially when everyone wants their shit to run on Android and iOS and Blackberry and WinMo all at once).
If you are comparing A8 performance vs A7 (as the title would imply you are), then you need to take into account the different screen sizes and pixel counts. The iPhone 6 has a fair bit more pixels that have to be pushed by the GPU.
Well, I'd suggest the right question is, how much does this one benchmark matter?
Well, the article does not even convince me that the benchmark was properly executed. When going from a 32-bit to a 64-bit architecture, you certainly need the code to be properly optimized for the new target architecture. For instance, if you do not use the new instructions, it is unlikely you will see a major performance improvement. If you normalize the benchmark result to clock speed and number of cores there is not much difference between the 2 processors.
So my guess is: they did not properly compile the benchmark.
According to Apple, the A8 draws 50% of the power of the A7. So it is a significant improvement. http://en.wikipedia.org/wiki/A...
What they're focussing on now is different. CPU is obviously almost good enough, battery is more important.
This... I want a longer battery, lighter weight, etc...
It is already fast enough and it will be awhile before apps catch up.
They will, but not for a few years, then we'll need another jump.
Yes, longer battery life would be nice but it's the bigger screen size and the fingerprint sensor that are motivating me to trade my iPhone 4S in for an iPhone 6+, I've decided that I want a phablet. It takes more effort to crack the fingerprint sensor than it takes to just sitting in your couch and punching in four digit pin-codes until you unlock the phone. I could put a password on my phone but punching in a password every time I get an e-mail is way too bothersome and I can't read Google maps in landscape mode on my iPhone 4S anymore because the display is just too small. As long as the device has adequate processing power to run the latest apps and games for the next 5 years and gets OS updates (which previous experience with Apple devices tells me it will) I don't really care that much about whether it has benchmarks and a processing speed that trumps those of the latest offering from Samsung, LG, HTC et al. In fact the majority of the features that I really value the most are software features ranging from the 'Continuity' OS X integration, 'HealthKit', App services and Universal Touch ID authorization for all apps to the little stuff you almost don't notice like, the revamped keyboard, built in phone calls over wifi, an overview over which app is using the most power, reply notification for especially important messages, ... the list goes on. Now if they'd only get around to putting a folding bookmarks menu in the little wizard you use when you add a bookmark in Mobile Safari... this is iOS version 8 for Christ's sake and Apple still hasn't gotten around to fixing it.
Only to idiots, are orders laws.
-- Henning von Tresckow
Basemark X results across all vendors are at http://results.rightware.com/b...
The iPhone 6 is around #17. iPhone 5s, #21.
Of course, everything else in the top 25 is running quad-core CPUs at 2+ GHz.
iPhones? Dual-core at 1.3-1.4 GHz.
That's some crazy math right there.
Village idiot in some extremely smart villages.
When going from a 32-bit to a 64-bit architecture, you certainly need the code to be properly optimized for the new target architecture. For instance, if you do not use the new instructions, it is unlikely you will see a major performance improvement.
There is absolutely no reason to expect a 64 bit architecture to be faster than a 32 bit architecture unless you are doing a lot of 64 bit operations, or need more than 4G of RAM.
Watch this Heartland Institute video
If you upgrade your phone frequently, it doesn't matter. But if you want to use it as long as possible, high performance is a must. Let's say iphone 7 or 8 is 2x-4x faster than iphone 6. Apps developed for iphone7/8 will lag heavily on the iphone 6 forcing you to upgrade your phone. That's what's happening today -- latest apps don't work on iphone two generations behind.
There is absolutely no reason to expect a 64 bit architecture to be faster than a 32 bit architecture unless you are doing a lot of 64 bit operations, or need more than 4G of RAM.
Right in theory, wrong in practice. If the only change was the width of the registers then it would make little difference to performance, but both the leading 32-bit architectures also gained more registers and new instructions when moving to a 64-bit architecture. ARM, in particular, made a number of performance-increasing changes to the architecure such as the removal of condition codes from most instructions.
So in practice 64 bit code usually runs faster. But don't take my word for it, look at the benchmarks for A7 running in 32 mode vs 64 bit mode.
It's why I never understand comparing Android and iOS benchmarks. We run benchmark software on them, compare the two, then run completely different operating systems and applications on top of them. Android benchmarks routinely show better performance than IOS. But everytime I use an Apple iPhone it "feels faster" and is completely stutter free.
There is absolutely no reason to expect a 64 bit architecture to be faster than a 32 bit architecture unless you are doing a lot of 64 bit operations, or need more than 4G of RAM.
Except if you know a few details of the Objective-C implementation in MacOS X and iOS. For example, in 64 bit many NSNumber and NSDate objects don't actually allocate any memory, but the 64 bit in the pointer contain all the data. In 64 bit, C++ std::string up to 22 chars in size don't allocate any memory. Retain/release are faster in 64 bits. memcpy or memset or memcmp or strlen run twice as fast.