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.
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...
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.
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.