Go Back   AnandTech Forums > Hardware and Technology > CPUs and Overclocking

Forums
· Hardware and Technology
· CPUs and Overclocking
· Motherboards
· Video Cards and Graphics
· Memory and Storage
· Power Supplies
· Cases & Cooling
· SFF, Notebooks, Pre-Built/Barebones PCs
· Networking
· Peripherals
· General Hardware
· Highly Technical
· Computer Help
· Home Theater PCs
· Consumer Electronics
· Digital and Video Cameras
· Mobile Devices & Gadgets
· Audio/Video & Home Theater
· Software
· Software for Windows
· All Things Apple
· *nix Software
· Operating Systems
· Programming
· PC Gaming
· Console Gaming
· Distributed Computing
· Security
· Social
· Off Topic
· Politics and News
· Discussion Club
· Love and Relationships
· The Garage
· Health and Fitness
· Merchandise and Shopping
· For Sale/Trade
· Hot Deals with Free Stuff/Contests
· Black Friday 2013
· Forum Issues
· Technical Forum Issues
· Personal Forum Issues
· Suggestion Box
· Moderator Resources
· Moderator Discussions
   

Reply
 
Thread Tools
Old 09-12-2013, 07:33 AM   #101
tipoo
Member
 
tipoo's Avatar
 
Join Date: Oct 2012
Posts: 174
Default

I find myself thinking that 64 bit support will be Apples next support cuttoff point, probably not with iOS8 but maybe 9. Just like when OSX went 64 bit, 32 bit machines were supported for some time, then they decided everything had to be 64 bit and support was dropped.

Now that GPU, it was listed only as "A7 GPU" in support docs (can't find the link now), while others were called SGX whatever GPUs. I wonder, is this their first in-house part? They were gobbling up GPU engineers. The driver number however seems consistent with SGX.

Last edited by tipoo; 09-12-2013 at 07:40 AM.
tipoo is offline   Reply With Quote
Old 09-12-2013, 07:42 AM   #102
Eug
Lifer
 
Eug's Avatar
 
Join Date: Mar 2000
Posts: 17,211
Default

Quote:
Originally Posted by tipoo View Post
I find myself thinking that 64 bit support will be Apples next support cuttoff point, probably not with iOS8 but maybe 9. Just like when OSX went 64 bit, 32 bit machines were supported for some time, then they decided everything had to be 64 bit and support was dropped.
Yes, that's what I suggested earlier in the thread, at iOS 10.

The only issue on Mac OS X though is that not all Macs with 64-bit CPUs were supported when this transition cutoff happened.
__________________

OS X: 27" iMac Core i7 870 | 13" MacBook Pro C2D 2.26 P8400 + SSD | 13" MacBook C2D 2.4 T8300 + SSD
iOS: iPad 2 | iPhone 5s
Windows: X3400 Athlon II X3 435 | 11.6" 1810TZ Pentium SU4100 + SSD | Revo R3610 Atom 330 + SSD
Android: Nexus 7 (2012)
Eug is online now   Reply With Quote
Old 09-12-2013, 07:48 AM   #103
USER8000
Senior Member
 
Join Date: Jun 2012
Posts: 482
Default

A daft question - is this an Apple designed 64 bit core or the first of the ARM A57 ones??
USER8000 is offline   Reply With Quote
Old 09-12-2013, 07:49 AM   #104
blackened23
Diamond Member
 
Join Date: Jul 2011
Posts: 8,556
Default

Quote:
Originally Posted by USER8000 View Post
A daft question - is this an Apple designed 64 bit core or the first of the ARM A57 ones??
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.
blackened23 is online now   Reply With Quote
Old 09-12-2013, 07:53 AM   #105
USER8000
Senior Member
 
Join Date: Jun 2012
Posts: 482
Default

Quote:
Originally Posted by blackened23 View Post
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.
USER8000 is offline   Reply With Quote
Old 09-12-2013, 08:00 AM   #106
NostaSeronx
Senior Member
 
Join Date: Sep 2011
Posts: 961
Default

Quote:
Originally Posted by tipoo View Post
Now that GPU, it was listed only as "A7 GPU" in support docs (can't find the link now), while others were called SGX whatever GPUs. I wonder, is this their first in-house part? They were gobbling up GPU engineers. The driver number however seems consistent with SGX.
G6400 to G6630, it is one these 3 GPUs.
NostaSeronx is offline   Reply With Quote
Old 09-12-2013, 12:02 PM   #107
Eug
Lifer
 
Eug's Avatar
 
Join Date: Mar 2000
Posts: 17,211
Default

Hmmm... Just FYI, Samsung's next smartphones will also be 64-bit.

http://www.koreatimes.co.kr/www/news...33_142604.html
__________________

OS X: 27" iMac Core i7 870 | 13" MacBook Pro C2D 2.26 P8400 + SSD | 13" MacBook C2D 2.4 T8300 + SSD
iOS: iPad 2 | iPhone 5s
Windows: X3400 Athlon II X3 435 | 11.6" 1810TZ Pentium SU4100 + SSD | Revo R3610 Atom 330 + SSD
Android: Nexus 7 (2012)
Eug is online now   Reply With Quote
Old 09-12-2013, 03:07 PM   #108
TerryMathews
Lifer
 
Join Date: Oct 1999
Posts: 11,474
Default

Quote:
Originally Posted by Eug View Post
Hmmm... Just FYI, Samsung's next smartphones will also be 64-bit.

http://www.koreatimes.co.kr/www/news...33_142604.html
Not surprising, some Android phones and tablets are already nearing 4GB of RAM.
__________________
Asrock Z87 Extreme4 | 4770K @ 4.6GHz (46x100 at 1.096V + 0.139V adaptive) | Noctua NH-D14 | 16GB RAM |2x MSI GTX 770 OC Dual Fan | Fractal Design Define R4 | QNIX QX2710 @ 2560x1440 96Hz
My Heatware evals
TerryMathews is offline   Reply With Quote
Old 09-12-2013, 09:05 PM   #109
Ajay
Platinum Member
 
Ajay's Avatar
 
Join Date: Jan 2001
Posts: 2,022
Default

Quote:
Originally Posted by blackened23 View Post
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.
Quote:
Originally Posted by USER8000 View Post
Thanks,actually I am quite impressed too they managed to get it out this year.
Yeah, I think this is the first shipping CPU w/ARM v8 architecture - unless I missed something.
__________________
Asus P6T V2 Deluxe Ci7 970 @ 4.2GHz w/HT, Corsair H100i, 2x240GB SanDisk Extreme RAID0, 2x WD VR 300GB RAID0, MSI GTX 680 PE @ 1110MHz, 12GB G.Skill Riojaws DDR3 1600, Corair 850HX, Corsair 800D case. Win7 x64 Ultimate. Dell U2412M.
Heatware
Ajay is offline   Reply With Quote
Old 09-12-2013, 11:36 PM   #110
Eug
Lifer
 
Eug's Avatar
 
Join Date: Mar 2000
Posts: 17,211
Default

Now on the Apple developer website:

About 64-Bit Cocoa Touch Apps
__________________

OS X: 27" iMac Core i7 870 | 13" MacBook Pro C2D 2.26 P8400 + SSD | 13" MacBook C2D 2.4 T8300 + SSD
iOS: iPad 2 | iPhone 5s
Windows: X3400 Athlon II X3 435 | 11.6" 1810TZ Pentium SU4100 + SSD | Revo R3610 Atom 330 + SSD
Android: Nexus 7 (2012)
Eug is online now   Reply With Quote
Old 09-13-2013, 06:01 AM   #111
Enigmoid
Golden Member
 
Join Date: Sep 2012
Posts: 1,319
Default

Quote:
Originally Posted by Eug View Post
Now on the Apple developer website:

About 64-Bit Cocoa Touch Apps
Says I need to log in. Can you copy the relevant material please?
Enigmoid is online now   Reply With Quote
Old 09-13-2013, 07:44 AM   #112
Eug
Lifer
 
Eug's Avatar
 
Join Date: Mar 2000
Posts: 17,211
Default

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

OS X: 27" iMac Core i7 870 | 13" MacBook Pro C2D 2.26 P8400 + SSD | 13" MacBook C2D 2.4 T8300 + SSD
iOS: iPad 2 | iPhone 5s
Windows: X3400 Athlon II X3 435 | 11.6" 1810TZ Pentium SU4100 + SSD | Revo R3610 Atom 330 + SSD
Android: Nexus 7 (2012)

Last edited by Eug; 09-13-2013 at 07:54 AM.
Eug is online now   Reply With Quote
Old 09-13-2013, 11:16 AM   #113
Mopetar
Platinum Member
 
Join Date: Jan 2011
Posts: 2,857
Default

Quote:
Originally Posted by TerryMathews View Post
Not surprising, some Android phones and tablets are already nearing 4GB of RAM.
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.
Mopetar is offline   Reply With Quote
Old 09-13-2013, 11:23 AM   #114
Exophase
Platinum Member
 
Join Date: Apr 2012
Posts: 2,179
Default

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.
Exophase is offline   Reply With Quote
Old 09-13-2013, 11:27 AM   #115
Eug
Lifer
 
Eug's Avatar
 
Join Date: Mar 2000
Posts: 17,211
Default

They wanted the ARMv8's cryptography support anyway. If they're going to use that core, why not properly implement 64-bit at the same time?

I don't see the downside.
__________________

OS X: 27" iMac Core i7 870 | 13" MacBook Pro C2D 2.26 P8400 + SSD | 13" MacBook C2D 2.4 T8300 + SSD
iOS: iPad 2 | iPhone 5s
Windows: X3400 Athlon II X3 435 | 11.6" 1810TZ Pentium SU4100 + SSD | Revo R3610 Atom 330 + SSD
Android: Nexus 7 (2012)
Eug is online now   Reply With Quote
Old 09-13-2013, 11:43 AM   #116
Cerb
Elite Member
 
Cerb's Avatar
 
Join Date: Aug 2000
Posts: 15,088
Default

Quote:
Originally Posted by Mopetar View Post
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.
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.
__________________
"The computer can't tell you the emotional story. It can give you the exact mathematical design, but what's missing is the eyebrows." - Frank Zappa

Last edited by Cerb; 09-13-2013 at 11:46 AM.
Cerb is offline   Reply With Quote
Old 09-13-2013, 12:40 PM   #117
VengenceIsMine
Member
 
Join Date: Aug 2013
Posts: 69
Default

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.
VengenceIsMine is offline   Reply With Quote
Old 09-13-2013, 12:43 PM   #118
VengenceIsMine
Member
 
Join Date: Aug 2013
Posts: 69
Default

Quote:
Originally Posted by Eug View Post
They wanted the ARMv8's cryptography support anyway. If they're going to use that core, why not properly implement 64-bit at the same time?

I don't see the downside.
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 by VengenceIsMine; 09-13-2013 at 12:45 PM.
VengenceIsMine is offline   Reply With Quote
Old 09-13-2013, 02:53 PM   #119
Exophase
Platinum Member
 
Join Date: Apr 2012
Posts: 2,179
Default

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

Quote:
Originally Posted by VengenceIsMine View Post
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.
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.

Quote:
Originally Posted by VengenceIsMine View Post
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.
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 by Exophase; 09-13-2013 at 02:59 PM.
Exophase is offline   Reply With Quote
Old 09-13-2013, 05:18 PM   #120
Ruiner1
Junior Member
 
Join Date: Sep 2013
Posts: 8
Default

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/9...d-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.
Ruiner1 is offline   Reply With Quote
Old 09-13-2013, 06:28 PM   #121
iluvdeal
Golden Member
 
Join Date: Nov 1999
Posts: 1,811
Default

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/16...ve-performance
iluvdeal is offline   Reply With Quote
Old 09-14-2013, 03:24 AM   #122
Nothingness
Senior Member
 
Join Date: Jul 2013
Posts: 537
Default

Quote:
Originally Posted by iluvdeal View Post
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/16...ve-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.
Nothingness is offline   Reply With Quote
Old 09-14-2013, 05:22 AM   #123
carop
Member
 
Join Date: Jul 2012
Posts: 40
Default

Quote:
Originally Posted by iluvdeal View Post
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/16...ve-performance
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/?...rpostid=136203
carop is offline   Reply With Quote
Old 09-14-2013, 07:15 AM   #124
Eug
Lifer
 
Eug's Avatar
 
Join Date: Mar 2000
Posts: 17,211
Default

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

OS X: 27" iMac Core i7 870 | 13" MacBook Pro C2D 2.26 P8400 + SSD | 13" MacBook C2D 2.4 T8300 + SSD
iOS: iPad 2 | iPhone 5s
Windows: X3400 Athlon II X3 435 | 11.6" 1810TZ Pentium SU4100 + SSD | Revo R3610 Atom 330 + SSD
Android: Nexus 7 (2012)

Last edited by Eug; 09-14-2013 at 07:45 AM.
Eug is online now   Reply With Quote
Old 09-14-2013, 08:05 AM   #125
Enigmoid
Golden Member
 
Join Date: Sep 2012
Posts: 1,319
Default

Quote:
Originally Posted by Eug View Post
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.
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")
Enigmoid is online now   Reply With Quote
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -5. The time now is 01:18 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.