So what this means for me as an enduser without an A7, is I will get updates for all my apps without actual updates but with larger universal binaries.
Sounds a bit like a period with my iPad2 where I got all these updates which didn't update anything but enlarged the footprint of all my apps (and gave space issues on my 16Gb version) because I needed to download all retina graphics etc.
Most universal apps shouldn't be much bigger than their 32-bit only versions. When you look inside of app bundles you will see that in most cases that the size of the app's graphics is much bigger than the size of the 32-bit executable. Since the 64-bit version can use the same graphics, the app should only need to include the 64-bit executable.
I think people don't get the "64-bit in a phone" thing: This is about transitioning up a base of thousands of developers to a brave new world:
iPhone: - 2013: 64-Bit in 5S, 2014: 64-Bit in 6C, 2015: All iPhone lineup is A7/64-bit minimum - iPhone/iOS 10 (2016/2017) when high-end phones have more than 4GB RAM, Apple can push a 64-Bit only iOS on pretty much all iPhones that are younger than 3 years (5s or higher) - At the same time Android wills till be all over the shop with different processors, different bitness, different graphics architectures, screen sizes, co processors - you name it.
iPad: 2013: iPad 5 in 64-Bit, 2014 64-Bit in iPad mini, 2015 Apple requires all iPad apps to have a 64-bit fork in the fat binary to get the last developers understand the importance.
AppleTV 4 2014: Apple TV 4 with A7 and 64 Bit with the ImagTech graphics engine - New Apple TV App Store - Positioned as casual game console - Developers can port iPad/iPhone games to the big screen with no ramp up time - Controlled via iPhone/iPad, new Apple Game controller or 3rd party Controller via BT
Macbook Air (ARM Edition) --> Think Chromebook, just in useful and with software 2015: - Apple announces new Macbook Air with MacOS for ARM on A8 processor (8GB RAM) & touchscreen - All new Mac Appstore applications need to provide fat binary (x86, ARM) - Can run iPad apps in a window. - Roadmap for all Mac to transition to ARM architecture until 2018
Okay. This is all a bit over the top, but this is what I believe the A7 stands for: An unprecedented move to a unified eco system of phone, tablet, set top box and desktop OS.
One company doing it all with the biggest developer community getting one 64-bit architecture for processor and graphics for all platforms with minimum transition time, QA & testing obstacles and supported by 500M credit cards registered by Apple.
It's not critical for creating or running an app, but we were talking about whether the original iOS was intended to run third-party apps, not whether it was technically capable of doing so.
No, we were debating whether it was purely a platform for showcasing web apps. My argument is that 3rd party apps were intended all along, and it just took a little longer to get there due to Jobs' tight/crazy release schedules and the need for prioritization.
Most universal apps shouldn't be much bigger than their 32-bit only versions. When you look inside of app bundles you will see that in most cases that the size of the app's graphics is much bigger than the size of the 32-bit executable. Since the 64-bit version can use the same graphics, the app should only need to include the 64-bit executable.
Most people mistakenly seem to think that 64- bit app is 2x the size of 32-bit. The size increase is fairly trivial, maybe a few percent. The instruction set of 64-bit arm is still 32-bits.
ever time these so call tech experts speak they show how much they do not know about technologies. Yes, apps at this time can not take advantage of the 64 bit architectures and most apps do not need this level of power. But to say a user will not see any performance difference is complete wrong. We all have to assume that iOS was written as 64bit native, therefore, the user will see OS is self running faster. You can also bet that Apple is working with developers so they can take advantage of the new architecture. Therefore it will not be long before those first apps show up for 5S only. Most likely they will be gaming apps and as we all know the ipad and ATV will soon have the 64bit A7.
Most applications spend most of their time within OS libraries. The more the OS libraries are optimised for 64-bit, the more the application benefits, even if it isn't enhanced much (if at all) itself.
The main performance benefit from ARMv8 in the integer world are where longs (64-bit ints) are used. Rather than storing around 6 longs across 12 available 32-bit registers, you can now store around 30 longs in the larger register file. In addition each ALU operation on these longs is done in half the time of doing it in 32-bit. Not all problems can make use of longs, but where they can, performance improvements will be drastic.
Also the larger and longer floating point registers (not NEON, but VFP) will result in major performance increases too.
XCode will create both 32-bit and 64-bit versions of applications for the foreseeable future, either as fat binaries or separate binaries that the Apple Store will use depending on the target device.
Most applications spend most of their time within OS libraries. The more the OS libraries are optimised for 64-bit, the more the application benefits, even if it isn't enhanced much (if at all) itself.
The main performance benefit from ARMv8 in the integer world are where longs (64-bit ints) are used. Rather than storing around 6 longs across 12 available 32-bit registers, you can now store around 30 longs in the larger register file. In addition each ALU operation on these longs is done in half the time of doing it in 32-bit. Not all problems can make use of longs, but where they can, performance improvements will be drastic.
Also the larger and longer floating point registers (not NEON, but VFP) will result in major performance increases too.
XCode will create both 32-bit and 64-bit versions of applications for the foreseeable future, either as fat binaries or separate binaries that the Apple Store will use depending on the target device.
Not to mention the built in crypto instructions which can have a major performance improvement on anything using secure socket layer SSL, or video/audio decryption.
"64-bit mobile ARM processors have been in the pipeline for a long time" is somewhat true, but you're missing the fact that they were targeting server applications. Nobody had any inkling of putting a 64-bit SoC in a phone.
More bullshit from you, Daniel. Even the long dead Symbian had a 64-bit roadmap.
What strikes me as interesting is that Samsung's JK Shin claimed that next year Galaxy S would sport 64-bit processing. They can't do this without Google's cooperation. So either Shin is speaking out of bravado or he is aware of Android's future timeline.
Either that or it'll run a hastily-recompiled version of Tizen with a 32-bit Android compatibility layer...
If the S4 was anything to go by, the 64-bit SoC will be too expensive for the market and so everywhere other than South Korea will get one powered by a 32-bit Snapdragon instead. 6 months after release they'll state that they've finally worked out how to get all 64 bits working at the same time and there will be a future software update to permit this.
"When iOS is executing on a 64-bit device, iOS includes separate 32-bit and 64-bit versions of the system frameworks. When all apps running on the device are compiled for the 64-bit runtime, iOS never loads the 32-bit versions of those libraries, which means that the system uses less memory and launches apps more quickly," Apple explains.
"Because all of the built-in apps already support the 64-bit runtime, it is to everyone?s benefit that all apps running on 64-bit devices be compiled for the 64-bit runtime, especially apps that support background processing. Even apps that are not performance sensitive gain from this memory efficiency."
This really means that, to begin with, the memory footprint for shared libraries in shared memory will double, and will in fact do so until the user gets rid of all 32 bit apps on his machine. And the footprint on the flash drive is going to be larger as well as fat versions of the libraries will be there.
So the benefits?
Except for calculations of integers larger than the 4G limit, not much. Floating point calculations will have more precision, but not necessarily speed since the CPU is not optimized for floating point operations.
There is a lot more is going on with ARM AArch64 architecture than solely 64 bit addressing. The current ARM v7 architecture has many legacy bottleneck and shortcomings, the registers and security layer was overly complex and limited. The new 64 bit architecture as gave them the chance to greatly modernize a + 20 years ISA. I will repeat my self, we don't know much yet about the A7 internal, but if you look at other previous 64 bit CPU like the Athlon 64 or the G5, there internal architecture was radically different then previous generation and gave a big performance boots even to unoptimized apps.
It's quite possible that Samsung will be the first Android OEM with a 64 bit ARM processor, and maybe they will develop for a smaller node than Apple is at now for the A7/A7X.
Still, the Apple A7 is in production, and Apple likely will have the A8 ready for tapeout with plenty of production ramp before the iPhone 6, and will likely be at a comparable node as Samsung's best effort, with the advantage for Apple of custom ARMv8.
What this says to me though, is that ARMv8 is going to be very expensive for Android OEM's to design in, save possibly for Samsung, leaving even less margin on the table to survive. Perhaps between Apple and Samsung, other Android OEM's will be effectively shut out of the premium smartphone market defined by 64bit.
Apple will also enjoy a first mover advantage of apps, many of which will be new category apps tailored to business and enterprise organizations.
Perhaps its time for Google to push ChromeOS through Motorola and deprecate Android as its premier smartphone OS, relegating it to undeveloped nations where the bulk of its growth will center.
Oracle/Sun has been offering 32 and 64 bit versions of the Java JVM for years now. Recently I had a customer who was having serious problems running their enterprise middleware software stack. The recommendation was to change from the 64 bit JVM from the 32 bit one since they were running on the ragged edge of memory utilization. The change was successful with no changes necessary to the middleware Java code...and trust me, it's a lot more code than runs on a phone. Also, they ended up using the 64 bit version of a Java 5 JVM (not the latest Java 7). So this capability has been around for YEARS.
JavaME had also existed for years when Android was conceived ~2005, but it still took 3 years to get Android into production.
Also, 64-bit Java is not designed with any intent to run on mobile devices. It runs like crap on desktop PCs, making the platform only ever successful in server deployment.
Also: let me remind you about Adobe Flash, which similarly "existed" years before Google & Adobe decided to make it work on mobiles. After years of trying 2008-2011, they shipped something but then abandoned it because it made no sense.
You also forget that the technical "realm of possibility" needs a viable business model backing it up.
Hopes and dreams of Android fans haven't resulted in app sales, And it's not enough to replicate the work of a company making 75% of the profits of the mobile industry.
I have to laugh when the Fandroids inevitably show up here to stir the pot.
richl - Unless you have some solid evidence to back up your claims, its nothing more than conjecture. The reality is that Apple has 64bit hardware and software going to market THIS WEEK (including apps). Android is eating dust...
It won't *hard* to follow. It will just take engineering effort - effort that is well understood, and effort that has already begun.
Agree. What strikes me as interesting is that Samsung's JK Shin claimed that next year Galaxy S would sport 64-bit processing. They can't do this without Google's cooperation. So either Shin is speaking out of bravado or he is aware of Android's future timeline.
It also means that Samsung's Exynos 6 chips that include 64-bit cores are already designed and taped out. It takes a very long time, relatively speaking, to go from chip design completion to product availability (9 to 12 months), so if they anticipate a product out next year for the S5 in around June/July, that means the chip's designed now.
But Apple do have that chip in product now, and that is a massive achievement, far earlier than people expected. The experience in 64-bit processors that Apple got when they bought PA Semi will have proven invaluable here. ARMv8 is very PowerPC like in some aspects, just with a different ISA in front of it all.
Can't say I completely agree. The definition of a workstation is not merely centered around the CPU. Graphics has a lot to with it too. So does the A7 have the computing and graphics performance of a workstation of a decade ago? Not quite, AFAIK.
If it's PowerVR Rogue, then it's probably achieving around 80-100 GFLOPS and supports OpenCL.
That is quite competitive with what workstations could do a decade ago. Look at how many PowerMac G5s it took to achieve that 10 TFLOP supercomputer in Virginia Tech. 1100 computers (http://www.technewsworld.com/story/31997.html). 10000 GFLOPS/1100 computers = 10 GFLOPS/computer.
Interesting that your 'evidence' is nothing more than wishful thinking.
As soon as there's some evidence that Google has 64 bit Android ready, let us know. Until then, Apple has a big head start.
Oh, and btw, make sure you tell us how easy it is to convert Android apps to 64 bit. The benchmark is the simple recompile required by iOS.
Android apps will run on 64-bit without a recompile. They're targeting a bytecode intermediary instruction set, it is the task of the Dalvik VM to JIT compile that into something to run on the target hardware. That's how the same Android binary runs flawlessly on ARM, x86 and MIPS currently.
Also don't make the mistake of thinking that Apple's ObjectiveC runtime doesn't incur any overhead, it is a managed code solution itself, it's just that it compiles to native code rather than an intermediary bytecode. Maybe one day Apple will ship LLVM intermediary object code... or another platform will.
(Well, NDK apps will require a recompile, of course).
What formosa said. I don't buy that the 32-64 bit distinction is important for smartphones. I do buy that Apple is in a unique position to have the whole lot work truly well in the long term -- decades forward -- on the same 64-bit system, and I buy the idea that having it all on the same system is a major advantage (although it really does beg the question of when Apple is going to incorporate touchscreens in their PCs). To take one example, the idea of being at an academic conference and being able to run serious statistical analysis on the fly on my cell phone to deal with a question in a panel is kind of cool, and the possibilities for seriously accelerating collaborative projects because of this are endless.
A roadmap is only prediction which doesn't translate into execution. There is no working version of 64 bit Symbian and never will.
Re-read what DED wrote. He said that no-one even predicted that there would be a move to 64-bit processors for smartphones.
EDIT: If you want proof, here's a presentation from ARM engineers written in 2011. ARM has been working on 64-bit CPUs since 2007 and one of the prime motivations is "a future need in ARM’s traditional markets" (e.g. smartphones, not servers).
Comments
Most universal apps shouldn't be much bigger than their 32-bit only versions. When you look inside of app bundles you will see that in most cases that the size of the app's graphics is much bigger than the size of the 32-bit executable. Since the 64-bit version can use the same graphics, the app should only need to include the 64-bit executable.
This is about transitioning up a base of thousands of developers to a brave new world:
iPhone:
- 2013: 64-Bit in 5S, 2014: 64-Bit in 6C, 2015: All iPhone lineup is A7/64-bit minimum
- iPhone/iOS 10 (2016/2017) when high-end phones have more than 4GB RAM, Apple can push a 64-Bit only iOS on pretty much all iPhones that are younger than 3 years (5s or higher)
- At the same time Android wills till be all over the shop with different processors, different bitness, different graphics architectures, screen sizes, co processors - you name it.
iPad:
2013: iPad 5 in 64-Bit, 2014 64-Bit in iPad mini, 2015 Apple requires all iPad apps to have a 64-bit fork in the fat binary to get the last developers understand the importance.
AppleTV 4
2014: Apple TV 4 with A7 and 64 Bit with the ImagTech graphics engine
- New Apple TV App Store
- Positioned as casual game console
- Developers can port iPad/iPhone games to the big screen with no ramp up time
- Controlled via iPhone/iPad, new Apple Game controller or 3rd party Controller via BT
Macbook Air (ARM Edition) --> Think Chromebook, just in useful and with software
2015:
- Apple announces new Macbook Air with MacOS for ARM on A8 processor (8GB RAM) & touchscreen
- All new Mac Appstore applications need to provide fat binary (x86, ARM)
- Can run iPad apps in a window.
- Roadmap for all Mac to transition to ARM architecture until 2018
Okay. This is all a bit over the top, but this is what I believe the A7 stands for: An unprecedented move to a unified eco system of phone, tablet, set top box and desktop OS.
One company doing it all with the biggest developer community getting one 64-bit architecture for processor and graphics for all platforms with minimum transition time, QA & testing obstacles and supported by 500M credit cards registered by Apple.
Take that, Microsoft, Google and Samsung.
Cheers Max
It's not critical for creating or running an app, but we were talking about whether the original iOS was intended to run third-party apps, not whether it was technically capable of doing so.
No, we were debating whether it was purely a platform for showcasing web apps. My argument is that 3rd party apps were intended all along, and it just took a little longer to get there due to Jobs' tight/crazy release schedules and the need for prioritization.
Most universal apps shouldn't be much bigger than their 32-bit only versions. When you look inside of app bundles you will see that in most cases that the size of the app's graphics is much bigger than the size of the 32-bit executable. Since the 64-bit version can use the same graphics, the app should only need to include the 64-bit executable.
Most people mistakenly seem to think that 64- bit app is 2x the size of 32-bit. The size increase is fairly trivial, maybe a few percent. The instruction set of 64-bit arm is still 32-bits.
ever time these so call tech experts speak they show how much they do not know about technologies. Yes, apps at this time can not take advantage of the 64 bit architectures and most apps do not need this level of power. But to say a user will not see any performance difference is complete wrong. We all have to assume that iOS was written as 64bit native, therefore, the user will see OS is self running faster. You can also bet that Apple is working with developers so they can take advantage of the new architecture. Therefore it will not be long before those first apps show up for 5S only. Most likely they will be gaming apps and as we all know the ipad and ATV will soon have the 64bit A7.
Most applications spend most of their time within OS libraries. The more the OS libraries are optimised for 64-bit, the more the application benefits, even if it isn't enhanced much (if at all) itself.
The main performance benefit from ARMv8 in the integer world are where longs (64-bit ints) are used. Rather than storing around 6 longs across 12 available 32-bit registers, you can now store around 30 longs in the larger register file. In addition each ALU operation on these longs is done in half the time of doing it in 32-bit. Not all problems can make use of longs, but where they can, performance improvements will be drastic.
Also the larger and longer floating point registers (not NEON, but VFP) will result in major performance increases too.
XCode will create both 32-bit and 64-bit versions of applications for the foreseeable future, either as fat binaries or separate binaries that the Apple Store will use depending on the target device.
Very interesting article. Most of the talks have been about the price of the 5c, but the big news is probably the 64 bit(s?) transition.
Most applications spend most of their time within OS libraries. The more the OS libraries are optimised for 64-bit, the more the application benefits, even if it isn't enhanced much (if at all) itself.
The main performance benefit from ARMv8 in the integer world are where longs (64-bit ints) are used. Rather than storing around 6 longs across 12 available 32-bit registers, you can now store around 30 longs in the larger register file. In addition each ALU operation on these longs is done in half the time of doing it in 32-bit. Not all problems can make use of longs, but where they can, performance improvements will be drastic.
Also the larger and longer floating point registers (not NEON, but VFP) will result in major performance increases too.
XCode will create both 32-bit and 64-bit versions of applications for the foreseeable future, either as fat binaries or separate binaries that the Apple Store will use depending on the target device.
Not to mention the built in crypto instructions which can have a major performance improvement on anything using secure socket layer SSL, or video/audio decryption.
"64-bit mobile ARM processors have been in the pipeline for a long time" is somewhat true, but you're missing the fact that they were targeting server applications. Nobody had any inkling of putting a 64-bit SoC in a phone.
More bullshit from you, Daniel. Even the long dead Symbian had a 64-bit roadmap.
What strikes me as interesting is that Samsung's JK Shin claimed that next year Galaxy S would sport 64-bit processing. They can't do this without Google's cooperation. So either Shin is speaking out of bravado or he is aware of Android's future timeline.
Either that or it'll run a hastily-recompiled version of Tizen with a 32-bit Android compatibility layer...
If the S4 was anything to go by, the 64-bit SoC will be too expensive for the market and so everywhere other than South Korea will get one powered by a 32-bit Snapdragon instead. 6 months after release they'll state that they've finally worked out how to get all 64 bits working at the same time and there will be a future software update to permit this.
Take this from DED
"When iOS is executing on a 64-bit device, iOS includes separate 32-bit and 64-bit versions of the system frameworks. When all apps running on the device are compiled for the 64-bit runtime, iOS never loads the 32-bit versions of those libraries, which means that the system uses less memory and launches apps more quickly," Apple explains.
"Because all of the built-in apps already support the 64-bit runtime, it is to everyone?s benefit that all apps running on 64-bit devices be compiled for the 64-bit runtime, especially apps that support background processing. Even apps that are not performance sensitive gain from this memory efficiency."
This really means that, to begin with, the memory footprint for shared libraries in shared memory will double, and will in fact do so until the user gets rid of all 32 bit apps on his machine. And the footprint on the flash drive is going to be larger as well as fat versions of the libraries will be there.
So the benefits?
Except for calculations of integers larger than the 4G limit, not much. Floating point calculations will have more precision, but not necessarily speed since the CPU is not optimized for floating point operations.
There is a lot more is going on with ARM AArch64 architecture than solely 64 bit addressing. The current ARM v7 architecture has many legacy bottleneck and shortcomings, the registers and security layer was overly complex and limited. The new 64 bit architecture as gave them the chance to greatly modernize a + 20 years ISA. I will repeat my self, we don't know much yet about the A7 internal, but if you look at other previous 64 bit CPU like the Athlon 64 or the G5, there internal architecture was radically different then previous generation and gave a big performance boots even to unoptimized apps.
iOS, as a platform for webapps? Give me a break!
So quickly that people forget.
It's quite possible that Samsung will be the first Android OEM with a 64 bit ARM processor, and maybe they will develop for a smaller node than Apple is at now for the A7/A7X.
Still, the Apple A7 is in production, and Apple likely will have the A8 ready for tapeout with plenty of production ramp before the iPhone 6, and will likely be at a comparable node as Samsung's best effort, with the advantage for Apple of custom ARMv8.
What this says to me though, is that ARMv8 is going to be very expensive for Android OEM's to design in, save possibly for Samsung, leaving even less margin on the table to survive. Perhaps between Apple and Samsung, other Android OEM's will be effectively shut out of the premium smartphone market defined by 64bit.
Apple will also enjoy a first mover advantage of apps, many of which will be new category apps tailored to business and enterprise organizations.
Perhaps its time for Google to push ChromeOS through Motorola and deprecate Android as its premier smartphone OS, relegating it to undeveloped nations where the bulk of its growth will center.
JavaME had also existed for years when Android was conceived ~2005, but it still took 3 years to get Android into production.
Also, 64-bit Java is not designed with any intent to run on mobile devices. It runs like crap on desktop PCs, making the platform only ever successful in server deployment.
Also: let me remind you about Adobe Flash, which similarly "existed" years before Google & Adobe decided to make it work on mobiles. After years of trying 2008-2011, they shipped something but then abandoned it because it made no sense.
You also forget that the technical "realm of possibility" needs a viable business model backing it up.
Hopes and dreams of Android fans haven't resulted in app sales, And it's not enough to replicate the work of a company making 75% of the profits of the mobile industry.
I have to laugh when the Fandroids inevitably show up here to stir the pot.
richl - Unless you have some solid evidence to back up your claims, its nothing more than conjecture. The reality is that Apple has 64bit hardware and software going to market THIS WEEK (including apps). Android is eating dust...
It won't *hard* to follow. It will just take engineering effort - effort that is well understood, and effort that has already begun.
Agree. What strikes me as interesting is that Samsung's JK Shin claimed that next year Galaxy S would sport 64-bit processing. They can't do this without Google's cooperation. So either Shin is speaking out of bravado or he is aware of Android's future timeline.
It also means that Samsung's Exynos 6 chips that include 64-bit cores are already designed and taped out. It takes a very long time, relatively speaking, to go from chip design completion to product availability (9 to 12 months), so if they anticipate a product out next year for the S5 in around June/July, that means the chip's designed now.
But Apple do have that chip in product now, and that is a massive achievement, far earlier than people expected. The experience in 64-bit processors that Apple got when they bought PA Semi will have proven invaluable here. ARMv8 is very PowerPC like in some aspects, just with a different ISA in front of it all.
Can't say I completely agree. The definition of a workstation is not merely centered around the CPU. Graphics has a lot to with it too. So does the A7 have the computing and graphics performance of a workstation of a decade ago? Not quite, AFAIK.
If it's PowerVR Rogue, then it's probably achieving around 80-100 GFLOPS and supports OpenCL.
That is quite competitive with what workstations could do a decade ago. Look at how many PowerMac G5s it took to achieve that 10 TFLOP supercomputer in Virginia Tech. 1100 computers (http://www.technewsworld.com/story/31997.html). 10000 GFLOPS/1100 computers = 10 GFLOPS/computer.
More bullshit from you, Daniel. Even the long dead Symbian had a 64-bit roadmap.
A roadmap is only prediction which doesn't translate into execution. There is no working version of 64 bit Symbian and never will.
Interesting that your 'evidence' is nothing more than wishful thinking.
As soon as there's some evidence that Google has 64 bit Android ready, let us know. Until then, Apple has a big head start.
Oh, and btw, make sure you tell us how easy it is to convert Android apps to 64 bit. The benchmark is the simple recompile required by iOS.
Android apps will run on 64-bit without a recompile. They're targeting a bytecode intermediary instruction set, it is the task of the Dalvik VM to JIT compile that into something to run on the target hardware. That's how the same Android binary runs flawlessly on ARM, x86 and MIPS currently.
Also don't make the mistake of thinking that Apple's ObjectiveC runtime doesn't incur any overhead, it is a managed code solution itself, it's just that it compiles to native code rather than an intermediary bytecode. Maybe one day Apple will ship LLVM intermediary object code... or another platform will.
(Well, NDK apps will require a recompile, of course).
A roadmap is only prediction which doesn't translate into execution. There is no working version of 64 bit Symbian and never will.
Re-read what DED wrote. He said that no-one even predicted that there would be a move to 64-bit processors for smartphones.
EDIT: If you want proof, here's a presentation from ARM engineers written in 2011. ARM has been working on 64-bit CPUs since 2007 and one of the prime motivations is "a future need in ARM’s traditional markets" (e.g. smartphones, not servers).