It is an in house custom CPU/GPU. It is not ARM A57. Their custom designs are quite impressive when looking at iPad benchmarks, actually.
Thanks,actually I am quite impressed too they managed to get it out this year.
Eug
Lifer
- Mar 11, 2000
- 23,586
- 1,000
- 126
Hmmm... Just FYI, Samsung's next smartphones will also be 64-bit.
http://www.koreatimes.co.kr/www/news/tech/2013/09/133_142604.html
http://www.koreatimes.co.kr/www/news/tech/2013/09/133_142604.html
Ajay
Lifer
- Jan 8, 2001
- 15,427
- 7,845
- 136
Yeah, I think this is the first shipping CPU w/ARM v8 architecture - unless I missed something.
Eug
Lifer
- Mar 11, 2000
- 23,586
- 1,000
- 126
Eug
Lifer
- Mar 11, 2000
- 23,586
- 1,000
- 126
Oh, sorry about that.
It's the "64-bit Transition Guide for Cocoa Touch" on their developer site, so lots of pages of recommendations on how to approach your iOS 64-bit code if you're a developer. Note, I'm not actually a developer, but the basic registration is free, so I registered years ago.
The intro page is below:
---
About 64-Bit Cocoa Touch Apps
When desktop operating systems transitioned from 32-bit to 64-bit addressing, 64-bit apps were critical to the OS transition. Now, iOS is getting a similar desktop-class architecture. Starting with iOS 7, you can build iOS apps that take advantage of 64-bit processors. An app that supports 64-bit processing almost always gains improved performance when compared with a 32-bit app running on the same device.
At a Glance
Among other architecture improvements, a 64-bit ARM processor includes twice as many integer and floating-point registers as earlier processors do. As a result, 64-bit apps can work with more data at once for improved performance. Apps that extensively use 64-bit integer math or custom NEON operations see even larger performance gains. In a 64-bit process, pointers are 64 bits and some integer types, once 32 bits, are now 64 bits. Many data types in system frameworks, especially UIKit and Foundation, have also changed. Generally, 64-bit apps run more quickly and efficiently than their 32-bit equivalents. However, the transition to 64-bit code brings with it increased memory usage. If not managed carefully, the increased memory consumption can be detrimental to an app’s performance.
Convert Your App to a 64-Bit Binary After Updating It for iOS 7
Xcode can build your app with both 32-bit and 64-bit binaries included. This combined binary requires a minimum deployment target of iOS 6 or later. The 64-bit binary runs only on iOS 7 or later. If you have an existing app, you should first update your app for iOS 7 and then port it to run on 64-bit processors. By updating it first for iOS 7, you can remove deprecated code paths and use modern practices. If you are creating a new app, target iOS 7 and compile 32-bit and 64-bit versions of your app.
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. 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.
Convert and Then Test Your App
The architecture for 64-bit apps on iOS is almost identical to the architecture for OS X apps, making it easy to create a common code base that runs in both operating systems. Converting a Cocoa Touch app to 64-bit follows a similar transition process as the one for Cocoa apps on OS X. Pointers and some common C types change from 32 bits to 64 bits. Code that relies on the NSInteger and CGFloat types needs to be carefully examined.
Start by building the app for the 64-bit runtime, fixing any warnings that occur as well as searching your code for specific 64-bit issues. For example:
Make sure all function calls have a proper prototype.
Avoid truncating 64-bit values by accidentally assigning them to a 32-bit data type.
Ensure that calculations are performed correctly in the 64-bit version of your app.
Create data structures whose layouts are identical in the 32-bit and 64-bit versions of your app (such as when you write a data file to iCloud).
Test your app on a 64-bit iOS device because some changes can be detected only when running on actual hardware. When your app is running, profile its performance and memory usage, improving both as necessary.
---
I find it interesting that they specifically comment about having 64-bit iOS makes it easier to have a common code base between iOS and OS X. Others have mentioned it here of course before, but the fact that they emphasize it somewhat suggests to me that Apple intends to transition quickly, like they did on OS X. At one key transition point, every iPhone and iPad and iPod touch that is not 64-bit will no longer be supported for new versions of iOS, regardless of the rest of its hardware. I could see this happening as early as 2016.
It's the "64-bit Transition Guide for Cocoa Touch" on their developer site, so lots of pages of recommendations on how to approach your iOS 64-bit code if you're a developer. Note, I'm not actually a developer, but the basic registration is free, so I registered years ago.
The intro page is below:
---
About 64-Bit Cocoa Touch Apps
When desktop operating systems transitioned from 32-bit to 64-bit addressing, 64-bit apps were critical to the OS transition. Now, iOS is getting a similar desktop-class architecture. Starting with iOS 7, you can build iOS apps that take advantage of 64-bit processors. An app that supports 64-bit processing almost always gains improved performance when compared with a 32-bit app running on the same device.
At a Glance
Among other architecture improvements, a 64-bit ARM processor includes twice as many integer and floating-point registers as earlier processors do. As a result, 64-bit apps can work with more data at once for improved performance. Apps that extensively use 64-bit integer math or custom NEON operations see even larger performance gains. In a 64-bit process, pointers are 64 bits and some integer types, once 32 bits, are now 64 bits. Many data types in system frameworks, especially UIKit and Foundation, have also changed. Generally, 64-bit apps run more quickly and efficiently than their 32-bit equivalents. However, the transition to 64-bit code brings with it increased memory usage. If not managed carefully, the increased memory consumption can be detrimental to an app’s performance.
Convert Your App to a 64-Bit Binary After Updating It for iOS 7
Xcode can build your app with both 32-bit and 64-bit binaries included. This combined binary requires a minimum deployment target of iOS 6 or later. The 64-bit binary runs only on iOS 7 or later. If you have an existing app, you should first update your app for iOS 7 and then port it to run on 64-bit processors. By updating it first for iOS 7, you can remove deprecated code paths and use modern practices. If you are creating a new app, target iOS 7 and compile 32-bit and 64-bit versions of your app.
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. 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.
Convert and Then Test Your App
The architecture for 64-bit apps on iOS is almost identical to the architecture for OS X apps, making it easy to create a common code base that runs in both operating systems. Converting a Cocoa Touch app to 64-bit follows a similar transition process as the one for Cocoa apps on OS X. Pointers and some common C types change from 32 bits to 64 bits. Code that relies on the NSInteger and CGFloat types needs to be carefully examined.
Start by building the app for the 64-bit runtime, fixing any warnings that occur as well as searching your code for specific 64-bit issues. For example:
Make sure all function calls have a proper prototype.
Avoid truncating 64-bit values by accidentally assigning them to a 32-bit data type.
Ensure that calculations are performed correctly in the 64-bit version of your app.
Create data structures whose layouts are identical in the 32-bit and 64-bit versions of your app (such as when you write a data file to iCloud).
Test your app on a 64-bit iOS device because some changes can be detected only when running on actual hardware. When your app is running, profile its performance and memory usage, improving both as necessary.
---
I find it interesting that they specifically comment about having 64-bit iOS makes it easier to have a common code base between iOS and OS X. Others have mentioned it here of course before, but the fact that they emphasize it somewhat suggests to me that Apple intends to transition quickly, like they did on OS X. At one key transition point, every iPhone and iPad and iPod touch that is not 64-bit will no longer be supported for new versions of iOS, regardless of the rest of its hardware. I could see this happening as early as 2016.
Last edited:
Not really a problem. Anything based on the Cortex-A15 like the Tegra 4 or the newer Exynos chips has a 40-bit addressable memory (although individual applications can't use more than ~4GB of RAM) so they have enough headroom for 1TB of RAM, which we're not going to get to anytime soon. There's no real worry or need to rush to using a 64-bit architecture.
PAE is an ugly hack and not something you want to rely on if you can help it. I'm not surprised in the least that Apple isn't pursuing it, support will probably never even enter their OS.
Cerb
Elite Member
- Aug 26, 2000
- 17,484
- 33
- 86
How many large databases are run on mobile ARM CPUs? RAM is not the problem. Virtual address space is the problem. If you need to work with data in one 4GB window, then some other data in another 4GB window, it gets ugly. And, by ugly, I mean that programmers are going to find a file-based method to do what they need to do, instead.
They're moving to 64-bit now, because they know they'll need it really soon. Windows got lots of hacks that made up 3.5GB of actual RAM workable, but TMK, FreeBSD, nor OS X since, did, and if not, it will show, just like with Linux, after 2GB+. Apple probably would have gone 64-bit sooner, if ARM had a standard for it. Even Apple can't get away with a custom CPU ISA, today. All Apple needs is to plan for a 2GB RAM tablet, and they'll have good reason for a 64-bit OS and apps.
Last edited:
ARM & Apple have a horribly long way to go to make that happen. On this chip side the A designs have nowhere near enough power to run MacOS as well as Intel currently does and if they try this they can kiss goodbye to what professional market they still have. A series chips have good graphics relative to the ARM world but they aren't in remotely in AMD or Nvidia's class at the high power end of the spectrum. Then there is the whole question of completely different UI paradigms (See Windows 8 Metro vs desktop) much less all the underlying OS architecture. Still 4-5 years away at least, if they try it before then, it will be the ugly parts Win 8 & RT all over again.
Agree, downsides are minor, increased register size will take up really small amounts of DRAM and storage but gaining cryp support and future app development for Ipad when it actually needs 64 bit + idiotic marketing hype in the meantime is worth the small tradeoff in the meantime.
Last edited:
Good to see at least one other person understands why going 64-bit now is saving Apple a headache and compromises on the OS side, thanks Cerb..
We really don't know what kind of performance and perf/W Apple could get if they scaled one of their custom ARM designs higher than Swift currently does. Or if they used a modified or entirely different uarch for this purpose. Just because they've made chips that are suitable for phones and tablets doesn't mean that this is the extent of performance they can achieve.
ARM really has nothing to do with it either, outside of licensing the architecture, which was already done years ago. The architecture plays little role in performance and there are already ARMv8 cores coming soon that will go well beyond tablet performance - the 3GHz X-Gene processor for instance.
Let's hope they aren't implementing register files with DRAM
The truth is that a) architectural register count between AArch32 and AArch64 is about the same because AArch32 bank switches a bunch of registers for other modes and AArch64 doesn't and b) in cutting edge OoO CPUs today (Swift probably at least somewhat falls under this category) the real register file will be a lot bigger than the architectural one to facilitate renaming. The (scalar) registers themselves are still 2x larger, though. The other places more space is needed is in supporting the 64-bit operations and 64-bit datapaths themselves, supporting execution resources for some stuff only in AArch64, and supporting separate decoding for both 32-bit and 64-bit modes.
We really don't know what kind of performance and perf/W Apple could get if they scaled one of their custom ARM designs higher than Swift currently does. Or if they used a modified or entirely different uarch for this purpose. Just because they've made chips that are suitable for phones and tablets doesn't mean that this is the extent of performance they can achieve.
ARM really has nothing to do with it either, outside of licensing the architecture, which was already done years ago. The architecture plays little role in performance and there are already ARMv8 cores coming soon that will go well beyond tablet performance - the 3GHz X-Gene processor for instance.
Let's hope they aren't implementing register files with DRAM
The truth is that a) architectural register count between AArch32 and AArch64 is about the same because AArch32 bank switches a bunch of registers for other modes and AArch64 doesn't and b) in cutting edge OoO CPUs today (Swift probably at least somewhat falls under this category) the real register file will be a lot bigger than the architectural one to facilitate renaming. The (scalar) registers themselves are still 2x larger, though. The other places more space is needed is in supporting the 64-bit operations and 64-bit datapaths themselves, supporting execution resources for some stuff only in AArch64, and supporting separate decoding for both 32-bit and 64-bit modes.
Last edited:
I was wondering if the reason for Apple jumping to armv8 now had anything to do with running out of virtual address space with >1GB RAM devices - depending upon how the memory map is arranged it's quite common to use up a few GB in kernel space.
Not being an iOS programmer and having no clue where to look, I googled and found a post on stackoverflow about mapping files which says you only get about 700MB, which sounds quite like 700MB user and 300MB for GPU shared memory.
http://stackoverflow.com/questions/...t-on-the-number-of-memory-mapped-files-in-ios
It at least seems plausible to me that you might pull the trigger early on 64-bit if you can rather than re-engineer it.
Not being an iOS programmer and having no clue where to look, I googled and found a post on stackoverflow about mapping files which says you only get about 700MB, which sounds quite like 700MB user and 300MB for GPU shared memory.
http://stackoverflow.com/questions/...t-on-the-number-of-memory-mapped-files-in-ios
It at least seems plausible to me that you might pull the trigger early on 64-bit if you can rather than re-engineer it.
I gotta say the level of insight from members of this board is really impressive. Someone reading an article like the following, really needs to come here instead:
http://www.extremetech.com/gaming/1...-marketing-fluff-and-wont-improve-performance
http://www.extremetech.com/gaming/1...-marketing-fluff-and-wont-improve-performance
When I read that article I started thinking the author probably deserved to be ignored for utter stupidity. Then I read the name: Joel Hruska. Disappointing.
Joel Hruska should study Operating Systems a bit before writing stupid articles.
Here is the first lesson from Linus Torvalds on large virtual address spaces:
http://www.realworldtech.com/forum/?threadid=136199&curpostid=136203
Eug
Lifer
- Mar 11, 2000
- 23,586
- 1,000
- 126
This guy predicts that A7 is TSMC 28 nm custom ARMv8 1.7 GHz dual-core CPU, quad Rogue G6430 GPU.
He also points out this article which suggests that the 5S has only 1 GB but LDDR3 RAM. But hey, at least it's lead free!
A6 was B8164B3PM
A7 is F8164A1PD
B - LDDR2
F - LDDR3
8164 - 1 GB RAM
It also suggests a non-Samsung manufacturer, based on chip markings from the leaked 5S logic board part, which based on rumours is TSMC.
He originally thought quad, but then saw the post from this guy who claims he has sources telling him that A7 is dual-core.
---
EDIT:
Heheh. I inadvertently left this up on my computer and then my wife came to check her email. She tried to read the post and was like, "WTF does all this crap mean?" She couldn't believe it when I said it was about a phone.
He also points out this article which suggests that the 5S has only 1 GB but LDDR3 RAM.
But hey, at least it's lead free! A6 was B8164B3PM
A7 is F8164A1PD
B - LDDR2
F - LDDR3
8164 - 1 GB RAM
It also suggests a non-Samsung manufacturer, based on chip markings from the leaked 5S logic board part, which based on rumours is TSMC.
He originally thought quad, but then saw the post from this guy who claims he has sources telling him that A7 is dual-core.
---
EDIT:
Heheh. I inadvertently left this up on my computer and then my wife came to check her email. She tried to read the post and was like, "WTF does all this crap mean?" She couldn't believe it when I said it was about a phone.
Last edited:
This guy predicts that A7 is TSMC 28 nm custom ARMv8 1.7 GHz dual-core CPU, quad Rogue G6430 GPU.
He also points out this article which suggests that the 5S has only 1 GB but LDDR3 RAM.
A6 was B8164B3PM
A7 is F8164A1PD
B - LDDR2
F - LDDR3
8164 - 1 GB RAM
It also suggests a non-Samsung manufacturer, based on chip markings from the leaked 5S logic board part, which based on rumours is TSMC.
He originally thought quad, but then saw the post from this guy who claims he has sources telling him that A7 is dual-core.
---
EDIT:
Heheh. I inadvertently left this up on my computer and then my wife came to check her email. She tried to read the post and was like, "WTF does all this crap mean?" She couldn't believe it when I said it was about a phone.
1GB RAM is beyond pathetic at this time.
Move to 64 bit CPU, put in 1 GB RAM.
(And I have suspicions that they might be right as apple didn't specifically say how much RAM the 5S would have, something they would have said if they put in 2GB--"Twice the power, twice the RAM")
1GB RAM is beyond pathetic at this time.
Move to 64 bit CPU, put in 1 GB RAM.
(And I have suspicions that they might be right as apple didn't specifically say how much RAM the 5S would have, something they would have said if they put in 2GB--"Twice the power, twice the RAM")
Apple didn't say anything about RAM the last time they doubled it, so why should they say it now?
TRENDING THREADS
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 9K
-
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes Discussion Threads
- Started by Tigerick
- Replies: 7K
-
Facebook
Twitter