The new architecture is interesting but 64 bit by itself is useless for now on a phone (as long as there is less than 4GB RAM), even more than Android's quad-core CPUs.
Other than more ram and support for larger integers in the main pipeline the difference between generation N 32 bit chips and N+1 64 bit chips is almost entirely stuff that could have been added while staying at 32bits.
Exactly, the "bitness" of a processor doesn't directly imply performance. The N64 had a 64-bit MIPS R4300 nearly two decades ago, but it's thoroughly outclassed by subsequent 32-bit CPUs. Nevertheless, now is as good a time as any for Apple to deploy a 64-bit ARM core. I wonder how long until Apple starts developing its own ARM cores for Macs...
What else is it for? I understand that calculations are still done in 32-bits (even x86 processors do that, only Itanium/IA64 class processors have 64bit datapath).
64 bit is mostly useful for some scientific applications. 99% of iOS apps out there would be fine with 16 bit (as long as they could address all the RAM)
It isn't a datapath thing. Currently, any precision math, or long hash work/encryption (common for apps using data) require 2 or 4 clocks to handle, which means higher consumption and lower performance. 64 bit registers means that drops to a theoretical 1/2 of power and clocks used to process. Which is a massive increase in throughput. Yes, most apps do not take advantage of this, but they will if they are apps that tend to eat CPU time.
64 means you can use 64 bit registers and arguments for instructions, typically per clock, so code that uses 64 arguments can be run faster, rather than spliting high precision / length instructions into two steps. This is especially good for reducing time spend on memory transactions, which means low power ram can be used, retaining high efficiency with improved performance. Plus this allows for virtualization (ARMs implementation) which can in turn mean sandboxing apps. Most apps may be natively written with 16 / 32 in mind, but using 64 does not necessarily mean they need to use loads of ram, using 16 megs of ram, with 64 bit registers can still yield performance boosts. This is essentially *doubling* the available resources / performance of the pipeline.
64 bit doesn't double de performance. Let say you add 1 + 1. It will be just as fast on 8, 16, 32 or 64 bits. If you need integers (not floating point) numbers higher than 4 billion, then 64 bit is faster. If you only use these numbers in 0.01% of you calculation, then you get a speed boost 0.01% of the time. They doubled the number of registers, which will improve performance (less transfers to RAM), but has nothing to do with 64 bit.
You do know that people use computers as something more than glorified calculators, right? Not all computing is "numeric," it involves other data types, like strings, and other operations, like logical comparisons.
Logical comparisons aren't faster on 64 bit. Only you can compare larger numbers at the same time. Branching isn't faster on 64 bit. Strings do not really benefit from 64 bit either. They are array of bytes. Where is the benefit of 64 bit?
My 32 BIT CRC run almost 2X faster when converted to 64 BIT. String copies and encryption run almost 2X faster (with no code changes) run almost 2X faster. Long word optimized string searches can also run faster in many cases by not doing simply "byte" wise operations.
Are the people who are implying 64-bit implies an automatic performance increase talking about x86? x86-64 is a weird case because you get twice the registers in long mode on an AMD64 CPU, which increases performance. That's not the case with other architectures, in fact outside of certain very specific usage cases (big scary scientific data processing) and the need to address more RAM - the performance difference is nil, or even worse a decrease due to shuffling about twice as much data... I can vouch for 32-bit userland being faster on the whole on UltraSPARC and PPC64 - I don't see why that wouldn't be the case on ARM unless there's something I don't know about the architecture.
But Apple have always been big on the marketing - they know 64-bit is useless on mobile... Of course the new architecture is very interesting for different reasons others have outlined here, but '64 bit' sounds impressive when you're faintly aware that previous mobile phones had 'less bits', no? Just like it did when Nintendo were marketing the N64....
For data paths of equal length, the 32 bit chip would be able to move more packets of data even though the throughput in raw GB/s would be the same.
Purely going to 64 bit has two main advantages: more addressable memory and fast 64 bit integer computation. When ARM and x86have gone 64 bit the architecture changed more than the size of the general purpose registers.
You could argue doubling of registers has nothing to do with 64 bit, had someone was building this processor from ground-up, but that's not the case here. ARM v8 ISA doubles the number of registers, and ARM v8 is 64 bit ISA, so doubling up registers would have been not possible without moving to 64 bit. Plus, there are other improvements ARM made to v8 over v7, so this argument of 64 bit "just preparing for larger memory" is really a huge overgeneralization, because the implementation of ARM v8 architecture, not just 64 bit, should provide performance improvement in many areas, just like how ARM's own A57 design generally performs better all around than A15 (they have similar pipeline, but A57 is v8 architecture whereas A15 is v7).
Your logic would be correct if a 64-bit ISA were the only way to execute instructions on 64-bit or larger data types, but that is not at all the case with the ARM v7/v8 ISA's. With Neon and VFPv4 extensions, the ARMv7 (32-bit ISA) is very capable of doing 64-bit data operations (http://infocenter.arm.com/help/index.jsp?topic=/co... Sure, 64-bit ISA's typically give you 64-bit general purpose registers (and 32-bit ISA's typically limit you to 32-bit general purpose registers), but those aren't the primary determinant of performance in throughput dominated workloads (implied by your comment about "available resources / performance of the pipeline"). FP/NEON registers are the limiting factor in this case, and ARM v7 (a 32-bit ISA) supports up to 64-bit registers in that domain.
Stated, not preached. I'm not religious, and nor is this a religion.
64Bit can related to either the address bus, the data bus or a set of registers. Typically the old description of the Bit was the address bus, relating to how much memory a system could address. This is not the case anymore as 64Bit mainly relates to the size of the general purposes registers, not the amount of RAM that is addressable.
Actually there's no need to have that much memory on iOS devices because it's far more memory efficient than either Windows Phone 8, BB10, Windows RT or Android. They won't put 4GB of memory on an iPad for a long time, maybe the next version will have 2GB if they find a sufficient use case for that but I'm sort of thinking not.
The OS which suffers data loss in Safari with just 2 tabs open and where many apps have to dump undo states if they are switched from is more efficient?
Is it? I'd like to see some data for that. All I know is that my work iPad2 is constantly having to refresh tabs in Safari due them being dumped for lack for memory.
It has nothing to do with memory efficiency. The OS itself requires a tiny amount of RAM. When we are talking about 2-4 GB RAM on a tablet, most RAM is used by the applications themselves. Just take a look on your PC how much RAM your web browser is using. 1GB is not enough for a $600+ device released in 2013.
Because obviously if you spend more on a computer you expect it to be more capable. At a certain price point, reduced functionality may be acceptable - but he's saying that $600 isn't that price.
Surprisingly enough, quad core CPU's in phones are nice. Honestly I think 3 cores are really all that is necessary but I can tell you there is a MASSIVE difference in performance between my Razr HD MAXX (2x1.5Ghz Krait) and my wife's HTC Ones (4x1.7Ghz Krait). And that is coming from first hand experience, not benchmarks or anything like that.
I agree on the three core thing. Two seems too few, even on the fastest hardware a background download and something just as graphically heavy as the app store can slow things to a crawl. 4 may seem excessive, 3 seems perfect but it's not feasible for mass fabrication.
Three seems good to me as well. All the benches seem to show that the 4th core is barely ever used so why not go with a 3 core? I had a 3 core Athlon and it was a great chip at the time.
Mobile SoCs are hotplugged anyway... so if the 4th core isn't used, it would be shut off. So why would you want to take away a core some heavy application can potentially use? It's not like it's hurting you when it's not being used.
The reason wouldn't be performance but better usage of die space. The area for an extra core could go to more cache, accelerators or bigger GPU. An SoC is balancing act of resources.
This makes no sense. How is 3 not feasable for mass fabrication? Not that it really matters, because you haven't made a strong case for why 3 cores is more desirable than 2.
If a background download slows things down to a crawl the software is either doing it wrong, or the bottleneck is elsewhere, like the wireless connection, or the speed of the flash memory.
Android works that way. It is using 2 cores, firing the 3th core under heavy load from time to time while the 4th core barely sees up-time at all. This is not a guess, but what most apps used for tweaking kernel settings will show you.
So, I agree with the people above, at this moment, 3 cores processors will be enough. I don't know how much cost savings will enable this ...
As for how fast is Krait 400 ... is fast. Coming from quad A9 to quad Krait 400 is very noticeable.
Anyway, at this point, the biggest improvement will be for Google to drop java ... but I guess it will not happen.
Your phones have different version of krait cores (200 vs 300) There is huge performance difference between said cores even if both your phones were quad cores, see here
Both are based from different Kraits to start with. On HTC One, it's actually based on Krait 300 (updated version of Krait) with higher DMIPS. Also, it's clocked much faster compared to OG Krait.
And for the perceived performance (UI fluidity, gaming, etc), HTC One is also at advantage due to the newer generation of GPUs Adreno inside its Snapdragon 600.
Your talking totally subjective experience, on 2 different models of phones with different implementations of Android possibly running very different setups in apps, background tasks etc. In other words Apples to Oranges.
A phone like the Moto X runs just fine with a duel core CPU just like iPhones do. More cores doesn't automatically mean better performance.
Exactly, bigger registers is what they are touting on the slides anyways. I am not an apple fanboy, but this is still exciting new for mobile, assuming develpers take advantage of it.
The developers most apt to take advantage of it are the people working on the compilers for XCode. I'm guessing that most other developers will take advantage of it by checking the box to compile a version of their app for the new ISA, something Apple will probably start requiring for App Store acceptance anyway.
I'm sure that there are some who will take more advantage of it, just as there have been some who still code critical codepaths in assember.
Why would Apple require to sacrifice 32bit compatibility? I hope there's far more to that than just having fat binaries available, which would be a huge bloat for all users. For starters it might be a good win if they just optimized the system to scream in 64bit code while the applications continue to boast only 32bit.
It surprised me as well, but 64bit isn't useless on a device with smaller memory.
First, being able to operate on larger chunks of data is useful for a variety of tasks that have nothing to do with big integers.
Second, a larger unified address space could help with things like large memory mapped files in flash, which is already much larger than 4GB. I don't know, but I wonder if it is also useful for certainly security approaches, like address space randomization.
My best guess is that there are multiple factors behind making the move now: First and foremost, that they need to get their eventually. Given this, it is a question of timing. Arguments in favor of making the change sooner rather than latter: Minimizes one source of differences between OSX and iOS. Silicon design investment in new ISA, rather than legacy ISA. More GP registers, option for wider operations, "marketing." Arguments against would be increased cost due to die area and power consumption, it would seem that those considerations were less significant.
And then there is always the possibility that they are going to be using these chips in another class of device all together...
Holy hell! Over 1 billion transistors? That's approaching the transistor count and die size of modern Intel desktop quad-core CPUs. Which I imagine would handily beat these 64-bit ARM cores in performance, though not necessarily power consumption. This is going to be an expensive chip to produce, that's for certain.
That likely includes the entire SoC which is more than the CPU. I bet most of those transistors are part of the new GPU... Can't wait to see what that is.
The transistor count for 4 core Haswell with GT2 graphics and hyperthreading is somewhere around 1.4 billion transistors and a 177 mm^2 die I believe, looking at the article here on Anandtech regarding it. So it's really not ~too~ far off. Not sure how the graphics component fairs against whatever's in this A7 chip but I bet the CPU horsepower is far, far below even a very low power 4 core Haswell.
A ULV HD 4000 was about 3 times faster than the iPad 4's GPU in GLBenchmark 2.7... probably around 4-5X faster than the iPhone 5's based on results of comparable chips (Adreno 320).
I'd imagine the gap is a bit smaller now, since Haswell GT2 doesn't double performance over the HD 4k.
but even ULV HD4000 had more power budget then a smartphone SOC. With more power budget, they could really ramp the frequencies, but Apple chooses to throw die area at their chips rather than frequency.
Keep in mind that one of the things people spend transistors on in mobile SoCs is special-function blocks that do tasks that could be done on the other cores, but do it with less power.
This is actually a technique that Intel has had to rely on heavily in order to be at all competitive with ARM SoC's in the phone and tablet space.
Again the 1,4 billion transistors in Haswell also includes GT2 I think? It's kind of hard to tell with the transistor count article here on Anandtech. Either way, the die size for GT2 is roughly 177 mm^2, which isn't ~that~ much larger.
The 1.4 billion transistor count and 177 mm^2 die size for Haswell is for a 4 core CPU with GT2 graphics, which I imagine are significantly more powerful than what's on this chip. The power consumption would be much higher, but I'm just saying, as large as this die is and as quickly as it's approaching the die size of desktop processors, pricing is going to go up up up.
Can't wait for the deep dive of this CPU, and the CPU in the 5C. Sounds like the A7 is built on 28nm HKMG, and I assume it implements armv8, of course. I wonder if the A6 in the 5C is re-spun on 28nm also, similar to what they did with the 32nm transition.
AMD has stuck 1.5B transistors into a 123mm^2 28nm die with Cape Verde (HD7770) or 2.1B on 160mm^2 28nm die with Bonaire (HD7790) as another example. nVidia too has put 1.3B on a 118mm^2 28nm die with GK107 or 2.6B on 221mm^2 with GK106. Those are considerably denser yet than 1B on 102mm^2 here so it is more than possible the A7 is 28nm.
Besides, only Intel has the capacity in 22nm to make Apple chips and they don't make chips for direct competitors.
No way, $10 says these are on Samsung's 28nm. TSMCs 20nm is not at the stage of being able to pump out this kind of volume and Intel are not providing their fabs, yet...
Note that this is an ISA change with doubling the general purpose registers and floating point registers. Not just a 64 bit pointer, which by itself isn't useful in a phone at the moment.
Don't forget that much of the kernel and APIs are shared between OS X and iOS. They dropped support for older 32-bit platforms from the OS X kernel. Now that iOS is running on 64-bit hardware, they can begin to have a unified 64-bit codebase again.
Not really. ARM and x86-64 are two different architectures. If you are going to compile for x86-64 and ARMv8, you might as well compile for x86-64 and ARMv7. They can't drop ARMv7 anyways, they just announced a brand new phone using it.
They might even start supporting ARM for Mac OS, which is what I've been trying to say for a while, and it's a whole lot more likely they would go that route than put Intel chips in iPhones and iPads (which is what Anand crazily sustains). This shows Apple is very committed to ARM chips. You'll never see Intel chips in iOS. Never. Ever.
Exactly. Apple has invested a LOT in the A-series chips to just toss them aside for an Intel chip that doesnt really offer anything over what Apple currently has.
They can't drop ARMv7, but they can start moving away from it, just as the move from 32 to 64 bit on OS X took multiple releases.
As for the fact that ARMv8 and x86-64 are different ISAs, so what? Generation of machine code by the compiler is just a small part of the difference between a 32-bit software stack and a 64-bit software stack. There are surely choices about data structures, and perhaps even algorithms influenced by the difference between 32 vs 64 bit that are otherwise agnostic to ISA (and endianness).
They are not any closer to moving away from ARMv7, because they just released a high end phone (don't tell me $600 is cheap for a phone) with ARMv7 in it. They will have to support it for years.
What I don't understand is how it can be twice as fast as A6 given its a similar die size (102mm2 vs 95mm2) and same process (TSMC 20nm). Sure there are some architecture gains w 64bit but they shouldn't be THAT dramatic...
Anand/Brian any thoughts you have on this wld be very welcome. Probly some gaming of benchmarks in there but it still looks a very strange gap...
Ah good spot... I was forgetting them moving from Samsung to apple foundry. Duh!
Still it's only a half node... I wonder what makes up the difference? Some core optimisation and benchmark jiggery pokers? Still seems a little bit of a stretch.
Simple: they try to not flat-out lie about their performance and rather search for some synthetic corner-case where they see the most improvement.. and that's what ends up on the marketing slides.
I'm guessing this is more about the future. Get developers writing in 64-bit APIs and in a year or two when we start seeing iPhones and/or iPads with 4+ GB of RAM we'll actually have applications that can take advantage of it.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
91 Comments
Back to Article
danbob999 - Tuesday, September 10, 2013 - link
The new architecture is interesting but 64 bit by itself is useless for now on a phone (as long as there is less than 4GB RAM), even more than Android's quad-core CPUs.xinthius - Tuesday, September 10, 2013 - link
64Bit isn't just for more addressable RAM.DanNeely - Tuesday, September 10, 2013 - link
Other than more ram and support for larger integers in the main pipeline the difference between generation N 32 bit chips and N+1 64 bit chips is almost entirely stuff that could have been added while staying at 32bits.somata - Tuesday, September 10, 2013 - link
Exactly, the "bitness" of a processor doesn't directly imply performance. The N64 had a 64-bit MIPS R4300 nearly two decades ago, but it's thoroughly outclassed by subsequent 32-bit CPUs. Nevertheless, now is as good a time as any for Apple to deploy a 64-bit ARM core. I wonder how long until Apple starts developing its own ARM cores for Macs...Tom123 - Wednesday, September 11, 2013 - link
In my opinion 64bit CPU is short path to Ax in MACs. Interesting is OpenGL ES 3.0 it mean new GPU. Rogue?PolishedMirror - Friday, November 19, 2021 - link
If you're still active here, they released their ARM-based cores on Macs on 2020So, 7 years?
andrei-z - Monday, September 12, 2022 - link
I guess we know now.name99 - Tuesday, September 10, 2013 - link
Don't be an idiot.The significant feature is NOT the 64-bitness, it is the ARMv8 ISA.
somata - Tuesday, September 10, 2013 - link
But what is the real significance of ARMv8 other than the 64-bit architecture?Kevin G - Wednesday, September 11, 2013 - link
More registers and it standardizes much of what was optional or open in previous ARM ISA revisions.mavere - Tuesday, September 10, 2013 - link
I think you're going to be repeating that line over and over for the next few weeks, as the commentariats dump their drivel.lilo777 - Tuesday, September 10, 2013 - link
"64Bit isn't just for more addressable RAM."What else is it for? I understand that calculations are still done in 32-bits (even x86 processors do that, only Itanium/IA64 class processors have 64bit datapath).
danbob999 - Tuesday, September 10, 2013 - link
x86-64 also have a 64 bit datapath.64 bit is mostly useful for some scientific applications. 99% of iOS apps out there would be fine with 16 bit (as long as they could address all the RAM)
danbob999 - Tuesday, September 10, 2013 - link
and the other 1% is fine with 32 bitninjaquick - Tuesday, September 10, 2013 - link
It isn't a datapath thing. Currently, any precision math, or long hash work/encryption (common for apps using data) require 2 or 4 clocks to handle, which means higher consumption and lower performance. 64 bit registers means that drops to a theoretical 1/2 of power and clocks used to process. Which is a massive increase in throughput. Yes, most apps do not take advantage of this, but they will if they are apps that tend to eat CPU time.ninjaquick - Tuesday, September 10, 2013 - link
64 means you can use 64 bit registers and arguments for instructions, typically per clock, so code that uses 64 arguments can be run faster, rather than spliting high precision / length instructions into two steps. This is especially good for reducing time spend on memory transactions, which means low power ram can be used, retaining high efficiency with improved performance. Plus this allows for virtualization (ARMs implementation) which can in turn mean sandboxing apps. Most apps may be natively written with 16 / 32 in mind, but using 64 does not necessarily mean they need to use loads of ram, using 16 megs of ram, with 64 bit registers can still yield performance boosts. This is essentially *doubling* the available resources / performance of the pipeline.danbob999 - Tuesday, September 10, 2013 - link
64 bit doesn't double de performance.Let say you add 1 + 1. It will be just as fast on 8, 16, 32 or 64 bits.
If you need integers (not floating point) numbers higher than 4 billion, then 64 bit is faster. If you only use these numbers in 0.01% of you calculation, then you get a speed boost 0.01% of the time.
They doubled the number of registers, which will improve performance (less transfers to RAM), but has nothing to do with 64 bit.
easp - Tuesday, September 10, 2013 - link
You do know that people use computers as something more than glorified calculators, right? Not all computing is "numeric," it involves other data types, like strings, and other operations, like logical comparisons.danbob999 - Tuesday, September 10, 2013 - link
Logical comparisons aren't faster on 64 bit. Only you can compare larger numbers at the same time. Branching isn't faster on 64 bit.Strings do not really benefit from 64 bit either. They are array of bytes. Where is the benefit of 64 bit?
StevenRN - Tuesday, September 10, 2013 - link
My 32 BIT CRC run almost 2X faster when converted to 64 BIT. String copies and encryption run almost 2X faster (with no code changes) run almost 2X faster. Long word optimized string searches can also run faster in many cases by not doing simply "byte" wise operations.Azurael - Wednesday, September 11, 2013 - link
Are the people who are implying 64-bit implies an automatic performance increase talking about x86? x86-64 is a weird case because you get twice the registers in long mode on an AMD64 CPU, which increases performance. That's not the case with other architectures, in fact outside of certain very specific usage cases (big scary scientific data processing) and the need to address more RAM - the performance difference is nil, or even worse a decrease due to shuffling about twice as much data... I can vouch for 32-bit userland being faster on the whole on UltraSPARC and PPC64 - I don't see why that wouldn't be the case on ARM unless there's something I don't know about the architecture.But Apple have always been big on the marketing - they know 64-bit is useless on mobile... Of course the new architecture is very interesting for different reasons others have outlined here, but '64 bit' sounds impressive when you're faintly aware that previous mobile phones had 'less bits', no? Just like it did when Nintendo were marketing the N64....
Kevin G - Wednesday, September 11, 2013 - link
The amusing thing here is that you're giving a case for 64 bit to be slower. Look at how the numbers are fully represented:0x00000000000000000000000000000001
Vs
0x0000000000000000000000000000000000000000000000000000000000000001
For data paths of equal length, the 32 bit chip would be able to move more packets of data even though the throughput in raw GB/s would be the same.
Purely going to 64 bit has two main advantages: more addressable memory and fast 64 bit integer computation. When ARM and x86have gone 64 bit the architecture changed more than the size of the general purpose registers.
kbk0000 - Wednesday, September 11, 2013 - link
You could argue doubling of registers has nothing to do with 64 bit, had someone was building this processor from ground-up, but that's not the case here. ARM v8 ISA doubles the number of registers, and ARM v8 is 64 bit ISA, so doubling up registers would have been not possible without moving to 64 bit. Plus, there are other improvements ARM made to v8 over v7, so this argument of 64 bit "just preparing for larger memory" is really a huge overgeneralization, because the implementation of ARM v8 architecture, not just 64 bit, should provide performance improvement in many areas, just like how ARM's own A57 design generally performs better all around than A15 (they have similar pipeline, but A57 is v8 architecture whereas A15 is v7).raptorious - Tuesday, September 10, 2013 - link
Your logic would be correct if a 64-bit ISA were the only way to execute instructions on 64-bit or larger data types, but that is not at all the case with the ARM v7/v8 ISA's. With Neon and VFPv4 extensions, the ARMv7 (32-bit ISA) is very capable of doing 64-bit data operations (http://infocenter.arm.com/help/index.jsp?topic=/co... Sure, 64-bit ISA's typically give you 64-bit general purpose registers (and 32-bit ISA's typically limit you to 32-bit general purpose registers), but those aren't the primary determinant of performance in throughput dominated workloads (implied by your comment about "available resources / performance of the pipeline"). FP/NEON registers are the limiting factor in this case, and ARM v7 (a 32-bit ISA) supports up to 64-bit registers in that domain.Daniel Egger - Tuesday, September 10, 2013 - link
But NEON always operates on 128bit. It's not efficient to do single 64bit operations using NEON at all.Hamranhansenhansen - Tuesday, September 17, 2013 - link
>> 64Bit isn't just for more addressable RAM.> What else is it for?
Running 64-bit code.
soryuuha - Tuesday, September 10, 2013 - link
xinthius..please defend/elobrate your comment. I would love to hear more about what you've preached.xinthius - Thursday, September 12, 2013 - link
Stated, not preached. I'm not religious, and nor is this a religion.64Bit can related to either the address bus, the data bus or a set of registers. Typically the old description of the Bit was the address bus, relating to how much memory a system could address. This is not the case anymore as 64Bit mainly relates to the size of the general purposes registers, not the amount of RAM that is addressable.
DanNeely - Tuesday, September 10, 2013 - link
I suspect it's mostly to maintain architecture parity with the upcoming iPad refresh. A 4GB phone this year would surprise me; a 4GB tablet would not.Krysto - Tuesday, September 10, 2013 - link
Apple will not put 4 GB of RAM in iPad. They're usually behind the curve in amount of RAM.Daniel Egger - Tuesday, September 10, 2013 - link
Actually there's no need to have that much memory on iOS devices because it's far more memory efficient than either Windows Phone 8, BB10, Windows RT or Android. They won't put 4GB of memory on an iPad for a long time, maybe the next version will have 2GB if they find a sufficient use case for that but I'm sort of thinking not.DarkXale - Tuesday, September 10, 2013 - link
The OS which suffers data loss in Safari with just 2 tabs open and where many apps have to dump undo states if they are switched from is more efficient?kyuu - Tuesday, September 10, 2013 - link
Is it? I'd like to see some data for that. All I know is that my work iPad2 is constantly having to refresh tabs in Safari due them being dumped for lack for memory.danbob999 - Tuesday, September 10, 2013 - link
It has nothing to do with memory efficiency. The OS itself requires a tiny amount of RAM. When we are talking about 2-4 GB RAM on a tablet, most RAM is used by the applications themselves. Just take a look on your PC how much RAM your web browser is using. 1GB is not enough for a $600+ device released in 2013.solipsism - Wednesday, September 11, 2013 - link
Since when is the amount of RAM needed by a system dependent on how much that device costs?doobydoo - Thursday, September 12, 2013 - link
Because obviously if you spend more on a computer you expect it to be more capable. At a certain price point, reduced functionality may be acceptable - but he's saying that $600 isn't that price.extide - Tuesday, September 10, 2013 - link
Surprisingly enough, quad core CPU's in phones are nice. Honestly I think 3 cores are really all that is necessary but I can tell you there is a MASSIVE difference in performance between my Razr HD MAXX (2x1.5Ghz Krait) and my wife's HTC Ones (4x1.7Ghz Krait). And that is coming from first hand experience, not benchmarks or anything like that.andykins - Tuesday, September 10, 2013 - link
I bet the software is completely different though so it's not exactly a fair comparison.tipoo - Tuesday, September 10, 2013 - link
I agree on the three core thing. Two seems too few, even on the fastest hardware a background download and something just as graphically heavy as the app store can slow things to a crawl. 4 may seem excessive, 3 seems perfect but it's not feasible for mass fabrication.Hubb1e - Tuesday, September 10, 2013 - link
Three seems good to me as well. All the benches seem to show that the 4th core is barely ever used so why not go with a 3 core? I had a 3 core Athlon and it was a great chip at the time.stacey94 - Tuesday, September 10, 2013 - link
Mobile SoCs are hotplugged anyway... so if the 4th core isn't used, it would be shut off. So why would you want to take away a core some heavy application can potentially use? It's not like it's hurting you when it's not being used.Kevin G - Wednesday, September 11, 2013 - link
The reason wouldn't be performance but better usage of die space. The area for an extra core could go to more cache, accelerators or bigger GPU. An SoC is balancing act of resources.easp - Tuesday, September 10, 2013 - link
This makes no sense. How is 3 not feasable for mass fabrication? Not that it really matters, because you haven't made a strong case for why 3 cores is more desirable than 2.If a background download slows things down to a crawl the software is either doing it wrong, or the bottleneck is elsewhere, like the wireless connection, or the speed of the flash memory.
etre - Wednesday, September 11, 2013 - link
Android works that way. It is using 2 cores, firing the 3th core under heavy load from time to time while the 4th core barely sees up-time at all. This is not a guess, but what most apps used for tweaking kernel settings will show you.So, I agree with the people above, at this moment, 3 cores processors will be enough. I don't know how much cost savings will enable this ...
As for how fast is Krait 400 ... is fast. Coming from quad A9 to quad Krait 400 is very noticeable.
Anyway, at this point, the biggest improvement will be for Google to drop java ... but I guess it will not happen.
Roland00Address - Tuesday, September 10, 2013 - link
Your phones have different version of krait cores (200 vs 300) There is huge performance difference between said cores even if both your phones were quad cores, see herehttp://www.anandtech.com/show/6747/htc-one-review/...
This Is It - Tuesday, September 10, 2013 - link
Not so fast, mate.Both are based from different Kraits to start with. On HTC One, it's actually based on Krait 300 (updated version of Krait) with higher DMIPS. Also, it's clocked much faster compared to OG Krait.
And for the perceived performance (UI fluidity, gaming, etc), HTC One is also at advantage due to the newer generation of GPUs Adreno inside its Snapdragon 600.
Jumangi - Tuesday, September 10, 2013 - link
Your talking totally subjective experience, on 2 different models of phones with different implementations of Android possibly running very different setups in apps, background tasks etc. In other words Apples to Oranges.A phone like the Moto X runs just fine with a duel core CPU just like iPhones do. More cores doesn't automatically mean better performance.
tuxRoller - Tuesday, September 10, 2013 - link
With 64bit you also get larger and, typically, more registers which are nothing but win.ninjaquick - Tuesday, September 10, 2013 - link
Exactly, bigger registers is what they are touting on the slides anyways. I am not an apple fanboy, but this is still exciting new for mobile, assuming develpers take advantage of it.easp - Tuesday, September 10, 2013 - link
The developers most apt to take advantage of it are the people working on the compilers for XCode. I'm guessing that most other developers will take advantage of it by checking the box to compile a version of their app for the new ISA, something Apple will probably start requiring for App Store acceptance anyway.I'm sure that there are some who will take more advantage of it, just as there have been some who still code critical codepaths in assember.
Daniel Egger - Tuesday, September 10, 2013 - link
Why would Apple require to sacrifice 32bit compatibility? I hope there's far more to that than just having fat binaries available, which would be a huge bloat for all users. For starters it might be a good win if they just optimized the system to scream in 64bit code while the applications continue to boast only 32bit.easp - Tuesday, September 10, 2013 - link
It surprised me as well, but 64bit isn't useless on a device with smaller memory.First, being able to operate on larger chunks of data is useful for a variety of tasks that have nothing to do with big integers.
Second, a larger unified address space could help with things like large memory mapped files in flash, which is already much larger than 4GB. I don't know, but I wonder if it is also useful for certainly security approaches, like address space randomization.
My best guess is that there are multiple factors behind making the move now: First and foremost, that they need to get their eventually. Given this, it is a question of timing. Arguments in favor of making the change sooner rather than latter: Minimizes one source of differences between OSX and iOS. Silicon design investment in new ISA, rather than legacy ISA. More GP registers, option for wider operations, "marketing." Arguments against would be increased cost due to die area and power consumption, it would seem that those considerations were less significant.
And then there is always the possibility that they are going to be using these chips in another class of device all together...
avishal - Sunday, September 15, 2013 - link
Great response!garadante - Tuesday, September 10, 2013 - link
Holy hell! Over 1 billion transistors? That's approaching the transistor count and die size of modern Intel desktop quad-core CPUs. Which I imagine would handily beat these 64-bit ARM cores in performance, though not necessarily power consumption. This is going to be an expensive chip to produce, that's for certain.darkcrayon - Tuesday, September 10, 2013 - link
That likely includes the entire SoC which is more than the CPU. I bet most of those transistors are part of the new GPU... Can't wait to see what that is.garadante - Tuesday, September 10, 2013 - link
The transistor count for 4 core Haswell with GT2 graphics and hyperthreading is somewhere around 1.4 billion transistors and a 177 mm^2 die I believe, looking at the article here on Anandtech regarding it. So it's really not ~too~ far off. Not sure how the graphics component fairs against whatever's in this A7 chip but I bet the CPU horsepower is far, far below even a very low power 4 core Haswell.stacey94 - Tuesday, September 10, 2013 - link
A ULV HD 4000 was about 3 times faster than the iPad 4's GPU in GLBenchmark 2.7... probably around 4-5X faster than the iPhone 5's based on results of comparable chips (Adreno 320).I'd imagine the gap is a bit smaller now, since Haswell GT2 doesn't double performance over the HD 4k.
Hubb1e - Tuesday, September 10, 2013 - link
but even ULV HD4000 had more power budget then a smartphone SOC. With more power budget, they could really ramp the frequencies, but Apple chooses to throw die area at their chips rather than frequency.easp - Tuesday, September 10, 2013 - link
Keep in mind that one of the things people spend transistors on in mobile SoCs is special-function blocks that do tasks that could be done on the other cores, but do it with less power.This is actually a technique that Intel has had to rely on heavily in order to be at all competitive with ARM SoC's in the phone and tablet space.
tipoo - Tuesday, September 10, 2013 - link
Higher clocked MP4 rather than MP3 maybe? 2x doesn't seem like it would need anything drastically new.madmilk - Tuesday, September 10, 2013 - link
x86-64 is fully capable of 64-bit computations, whoever told you otherwise is wrong.madmilk - Tuesday, September 10, 2013 - link
Huh, that's strange. That comment shouldn't have ended up here.danbob999 - Tuesday, September 10, 2013 - link
most transistors are in the GPU part. A recent Nvidia GPU has over 7 billion.garadante - Tuesday, September 10, 2013 - link
Again the 1,4 billion transistors in Haswell also includes GT2 I think? It's kind of hard to tell with the transistor count article here on Anandtech. Either way, the die size for GT2 is roughly 177 mm^2, which isn't ~that~ much larger.tipoo - Tuesday, September 10, 2013 - link
The CPU cores in these SoCs is actually a minority of the transistors though. The rest is uncore, GPU, etc.garadante - Tuesday, September 10, 2013 - link
The 1.4 billion transistor count and 177 mm^2 die size for Haswell is for a 4 core CPU with GT2 graphics, which I imagine are significantly more powerful than what's on this chip. The power consumption would be much higher, but I'm just saying, as large as this die is and as quickly as it's approaching the die size of desktop processors, pricing is going to go up up up.michael2k - Wednesday, September 11, 2013 - link
You forget that Apple's current SoC cost is something like $11 to $15 dollars.Going 'up' means $25 dollars.
Compare that to Haswell, where the cheapest mobile part is something like $200 or $150.
Even Atom costs something like $35.
extide - Tuesday, September 10, 2013 - link
Can't wait for the deep dive of this CPU, and the CPU in the 5C. Sounds like the A7 is built on 28nm HKMG, and I assume it implements armv8, of course. I wonder if the A6 in the 5C is re-spun on 28nm also, similar to what they did with the 32nm transition.Stuka87 - Tuesday, September 10, 2013 - link
With the transistor count, and that die size, there is no way its 28nm. I would bet money its 22.leecbaker - Tuesday, September 10, 2013 - link
Isn't Intel the only company with a fab currently making SOCs at a process that small? I'm still betting on 28nm.michael2k - Wednesday, September 11, 2013 - link
Actually, no, TMSC is at 20nm currently.danielfranklin - Wednesday, September 11, 2013 - link
Not at this kind of volume, no way its on TSMC's 20nm. Samsung 28nm for sure.frostyfiredude - Tuesday, September 10, 2013 - link
AMD has stuck 1.5B transistors into a 123mm^2 28nm die with Cape Verde (HD7770) or 2.1B on 160mm^2 28nm die with Bonaire (HD7790) as another example. nVidia too has put 1.3B on a 118mm^2 28nm die with GK107 or 2.6B on 221mm^2 with GK106. Those are considerably denser yet than 1B on 102mm^2 here so it is more than possible the A7 is 28nm.Besides, only Intel has the capacity in 22nm to make Apple chips and they don't make chips for direct competitors.
Kevin G - Friday, September 13, 2013 - link
Though Intel has loosened up a little is an fabbing chips for other companies. Mainly FPBGA and some networking gear.The real oddity about Intel's efforts is that they're not part of the US government's Trusted Foundry program.
danielfranklin - Wednesday, September 11, 2013 - link
No way, $10 says these are on Samsung's 28nm. TSMCs 20nm is not at the stage of being able to pump out this kind of volume and Intel are not providing their fabs, yet...tech01x - Tuesday, September 10, 2013 - link
Note that this is an ISA change with doubling the general purpose registers and floating point registers. Not just a 64 bit pointer, which by itself isn't useful in a phone at the moment.Eidigean - Tuesday, September 10, 2013 - link
Don't forget that much of the kernel and APIs are shared between OS X and iOS. They dropped support for older 32-bit platforms from the OS X kernel. Now that iOS is running on 64-bit hardware, they can begin to have a unified 64-bit codebase again.danbob999 - Tuesday, September 10, 2013 - link
Not really. ARM and x86-64 are two different architectures. If you are going to compile for x86-64 and ARMv8, you might as well compile for x86-64 and ARMv7.They can't drop ARMv7 anyways, they just announced a brand new phone using it.
Flunk - Tuesday, September 10, 2013 - link
Right, it doesn't matter one bit that they've dropped i386 support. ARM v7 is totally unrelated.Krysto - Tuesday, September 10, 2013 - link
They might even start supporting ARM for Mac OS, which is what I've been trying to say for a while, and it's a whole lot more likely they would go that route than put Intel chips in iPhones and iPads (which is what Anand crazily sustains). This shows Apple is very committed to ARM chips. You'll never see Intel chips in iOS. Never. Ever.Stuka87 - Tuesday, September 10, 2013 - link
Exactly. Apple has invested a LOT in the A-series chips to just toss them aside for an Intel chip that doesnt really offer anything over what Apple currently has.easp - Tuesday, September 10, 2013 - link
They can't drop ARMv7, but they can start moving away from it, just as the move from 32 to 64 bit on OS X took multiple releases.As for the fact that ARMv8 and x86-64 are different ISAs, so what? Generation of machine code by the compiler is just a small part of the difference between a 32-bit software stack and a 64-bit software stack. There are surely choices about data structures, and perhaps even algorithms influenced by the difference between 32 vs 64 bit that are otherwise agnostic to ISA (and endianness).
danbob999 - Tuesday, September 10, 2013 - link
They are not any closer to moving away from ARMv7, because they just released a high end phone (don't tell me $600 is cheap for a phone) with ARMv7 in it. They will have to support it for years.yasinag - Tuesday, September 10, 2013 - link
may be apple building their own CPUs for iphone and mac's.Jon Tseng - Wednesday, September 11, 2013 - link
What I don't understand is how it can be twice as fast as A6 given its a similar die size (102mm2 vs 95mm2) and same process (TSMC 20nm). Sure there are some architecture gains w 64bit but they shouldn't be THAT dramatic...Anand/Brian any thoughts you have on this wld be very welcome. Probly some gaming of benchmarks in there but it still looks a very strange gap...
davidcTecher - Wednesday, September 11, 2013 - link
Where do you see that they're the same fab process? http://en.wikipedia.org/wiki/Apple_system_on_chips says A6 is 32nm and A7 is 28nmJon Tseng - Wednesday, September 11, 2013 - link
Ah good spot... I was forgetting them moving from Samsung to apple foundry. Duh!Still it's only a half node... I wonder what makes up the difference? Some core optimisation and benchmark jiggery pokers? Still seems a little bit of a stretch.
MrSpadge - Wednesday, September 11, 2013 - link
Simple: they try to not flat-out lie about their performance and rather search for some synthetic corner-case where they see the most improvement.. and that's what ends up on the marketing slides.psuedonymous - Wednesday, September 11, 2013 - link
Wasn't the Razr-i the first phone with a 64-bit SoC (the Atom Z2480)? Or is the A7 'more 64-bit' in some ineffable way than the Z2480?KitsuneKnight - Wednesday, September 11, 2013 - link
The Atom Z2480 is actually only 32bits, according to the Wikipedia Atom SoC page.KPOM - Wednesday, September 11, 2013 - link
I'm guessing this is more about the future. Get developers writing in 64-bit APIs and in a year or two when we start seeing iPhones and/or iPads with 4+ GB of RAM we'll actually have applications that can take advantage of it.