
Apple’s iPhone 5s, the A7 Chip, and That 64-Bit Question - r0h1n
http://allthingsd.com/20130913/apples-iphone-5s-the-a7-chip-and-that-64-bit-question
======
rayiner
I think the journos are missing the point entirely here. Apple is playing up
'64-bit' because it's an easy shorthand for people to understand. The salient
benefit isn't the 64-bit address space per se, but the benefits of a next-
generation architecture. Compare with ARM: the difference between Cortex A15
and Cortex A57 isn't just the register width or even ARMv8. The latter is a
more sophisticated architecture overall. That's what Apple is using "64-bit"
to refer to in this context--a post-Cortex A15-class chip.

~~~
slantyyz
>> The salient benefit isn't the 64-bit address space per se, but the benefits
of a next-generation architecture.

This is what I thought too..

So is Gruber exaggerating when he says "There are serious performance gains by
going 64-bit. Addressing more than 4 GB of memory is not the only advantage"?

[http://daringfireball.net/linked/2013/09/12/samsung-64](http://daringfireball.net/linked/2013/09/12/samsung-64)

~~~
wmf
ARMv8 has twice as many registers which can improve performance.

~~~
UnoriginalGuy
Only available in 64 bit mode. Which most apps won't be.

~~~
glhaynes
Most, perhaps, if we're talking about the whole set of apps on the App Store.
But I think it's very likely that the vast majority of very popular, "use 20
times a day" apps will be 64-bit very soon.

------
pohl
The article only points out the double integer registers that AArch64 brings
to the table.

What interests me more are the doubled FP registers available to SIMD
instructions. Would all of the image processing that is done automatically by
the new camera software in the 5S have even been possible without this added
performance? I suspect this is a benefit of AArch64 that can be directly
linked to a specific user experience.

In addition, there are other interesting across-the-board performance
improvements enabled by 64bit pointers. Namely, the same one that they got on
the desktop OS when Lion was introduced:

 _Apple has apparently taken advantage of the 64-bit runtime in Lion by
optimizing the Objective C runtime itself to use some of these extra bits for,
shall we say, clever purposes. Bavarious describes an optimization through
which Apple is able to replace previously full-fledged opaque objects such as
NSNumber with an object-placeholder that exists entirely as the 64-bit “object
address” itself. This means that, for a wide range of “simple” objects, no
additional memory allocation is required, and no retain /release memory
management is required for the “object.”_

[http://www.red-sweater.com/blog/1947/bit-hacking](http://www.red-
sweater.com/blog/1947/bit-hacking)

~~~
masklinn
> Namely, the same one that they got on the desktop OS when Lion was
> introduced:

That's just a tagged pointer, language runtimes have been doing that for
decades (lisp machines even had hardware support for tagged pointers)

~~~
pohl
Of course, but more bits provide more opportunities to do this. (I didn't mean
to suggest that Apple invented tagged pointers. The question at hand was what
benefits come from a 64bit processor.)

------
el_duderino
Since everyone seems to have an opinion about the iPhone 5s having a 64-bit
processor, here's mine.

In the immediate future, this will make zero difference for consumers.
Applications that ship today will continue to be compiled as 32-bit, so that
they can run on all the other iOS devices as well. Since the iPhone 5s is
likely to be faster than all those other iOS devices as well, there's little
point right now optimizing an application for the iPhone 5s, everything that
runs well enough on an iPhone 4s or iPhone 5 or iPhone 5c will run well enough
on an iPhone 5s as well. Optimize for the low end, and the high end will take
care if itself.

In the medium term, there will come a moment in time when all supported iOS
devices have 64-bit support, with Apple dropping support for 32-bit devices.
At that point, the iPhone 5s will be the oldest supported iOS devices, and the
iPhone 5c won't be supported any more. Indirectly, that means that the iPhone
5s will have a longer useful life than the iPhone 5c, and since the difference
between 32-bit and 64-bit is qualitative and not quantitative, it's possible
that the useful life of an iPhone 5s will be more than one year longer than
that of the iPhone 5c. Users who care about how long they can keep their
phones before being forced to replace them because of obsolescence could
consider the more expensive iPhone 5s over an iPhone 5c on this point alone,
regardless of the other differences.

Finally, 64-bit support in the iPhone 5s is a great stepping stone for
developers. Even though deploying 64-bit-only applications might not be
practical for another few years, it's never too early to make sure that code
compiles for 64-bit targets and passes all the unit tests, to run
microbenchmarks, and maybe even for some dogfooding. In the long term, I can't
rule out that Apple would remove 32-bit support entirely and would therefore
mandate 64-bit applications, and it's probably easier to get ready on an
ongoing basis than to go through a 64-bit fire drill many years down the road.

~~~
anfedorov
Sounds familiar:
[https://plus.google.com/u/1/112218872649456413744/posts/Gbdj...](https://plus.google.com/u/1/112218872649456413744/posts/Gbdj4XnE2QK)

------
Symmetry
That was a remarkably poor article. Doubling your registers won't get you
anywhere near to doubling your performance on real world code, especially when
you already have a decent number of registers like 16. Out of order chips like
Apples that have caches they can hide the latency to in particular make this
less of an issue. There are some integer loads that'll see something close to
doubling performance from moving from 32 to 64 bit arithmetic, though.

Also, Android doesn't use Oracle's JVM. It uses Dalvik which Oracle doesn't
control. And Linux already supports 64-bit operation and has for a long time.
It's only recently supported 64-bit ARM, though, and Android will need to grab
a more recent version of the Linux kernel if they want to use 64-bit ARM.

When Android supports 64-bit ARM they'll also benefit much more than Apple
from the main advantage of 64-bit addressing when using less than 4 GB of
memory: easier garbage collection. The larger your address space the less a
random collection of bits will happen to constitute a valid pointer to a
memory location.

~~~
Steko
_remarkably poor article. Doubling your registers won 't get you anywhere near
to doubling your performance on real world code_

Did you even read the article?

"Double the register file adds a few percent to performance,” he said. “It’s a
deep compiler and runtime VM issue. … So marginal improvements for most apps,
at best."

~~~
Zarathust
The article has a lot of conflicting statements about this, which makes it
rather poor.

“This means that for some codes, the A7 will be twice as fast (or faster
depending on how many memory accesses the original code had) to run code
because the processor doesn’t have to use main memory as much.”

------
devx
Android 4.4 is likely to get at the very least the Linux kernel 3.8 (if not
3.10), which includes support for ARMv8. Granted, that doesn't necessarily
mean Android 4.4 will be "64-bit Android", and they'll probably wait at least
until Android 5.0 for that (hopefully to be released no longer than Google I/O
2014).

But I'm not sure if the kernel support will be enough for Android to be
"64-bit", or if they need to make the Dalvik VM 64-bit, too? And can they even
make Dalvik support both 64-bit and 32-bit, or how would that work?

I've just read this part:

> “This will not be true with Android, by the way. The Android Java app and
> native app environment will need support from Oracle, who owns the Java
> environment.

That almost makes you disregard everything that guy said prior to that. He
probably thinks Google is actually using the JVM.

~~~
cageface
There are some real downsides to Dalvik/Java as a mobile toolkit, but at least
the Android transition to 64-bit should be relatively smooth because there
really shouldn't be too many apps out there now with the wrong assumptions
about the size of ints & pointers.

Native code is a different story, of course.

------
mgraczyk
One interesting point that I haven't heard talked about nearly enough is that
now Apple has ported its kernel and build infrastructure to A64. iOS and OS X
share a great deal of code, so it wouldn't be crazy to predict that Apple may
move to put their next generation of "Desktop Class" (hint hint) A64 chips in
the Air or Macbook Pro.

Now that Apple has their kernel running on a modern 64 bit architecture, it
would almost be crazy for them NOT to focus on putting their specially
optimized A8 core into their notebooks.

------
rythie
At some point Apple is going to discontinue 32bit iOS - just like they did
with OSX, they need about 3 years before they can do this. It makes sense to
start early, because at some point they'll only be making devices with 4GB+ of
memory (samsung already make 3GB phone).

~~~
tadfisher
You don't need a 64-bit architecture to address more than 4GB of memory. The
real benefit is the architecture update.

~~~
reaperhulk
Unless your ARM has LPAE you do. I'm unsure if any ARMv7 chips out there are
using LPAE yet? Anybody know?

(Memory addressing info from ARM re: LPAE and ARMv8:
[http://infocenter.arm.com/help/topic/com.arm.doc.den0001c/DE...](http://infocenter.arm.com/help/topic/com.arm.doc.den0001c/DEN0001C_principles_of_arm_memory_maps.pdf))

~~~
mbell
If you're addressing more than 4GB of physical memory (actually, ~3 to 3.5GB
ish), you're using PAE, 32 vs 64 bit doesn't have any relevance to this. ARMv8
still uses a modified version of LPAE and x86_64 also uses an extension of PAE
when running in 64bit mode. I don't know of a 64 bit architecture that doesn't
use a PAE style table mapping system, i.e. none are directly addressing
physical memory (I'm sure there is an arch out there somewhere that does, just
not one I know of one in common use).

------
dmdeller
> What about immediate improvements to battery life? Teich thinks that’s
> unlikely. “The only way battery life gets better with greater than 32-bit
> address spaces is to prevent swapping apps from physical memory to either
> SSD or HDD and then back again,” he said.

iOS does not use a swap file[1] the way he is describing.

[1]:
[https://developer.apple.com/library/ios/documentation/Perfor...](https://developer.apple.com/library/ios/documentation/Performance/Conceptual/ManagingMemory/Articles/AboutMemory.html)
\- fourth paragraph

------
devx
Mac devs, has Apple started doing anything that could show they're preparing
to port Mac OS to ARM in the near future?

I have this feeling Apple will "inevitably" put Mac OS on its own ARMv8 chips
once they get "powerful enough" to sustain a "full OS" like Mac OS (they might
wait until A8 or A9 to do that), and then sell like a $700 Air-like machine
with keyboard and a larger screen than iPad, that would still be very
profitable for them, because of how little an ARM chip costs compared to Intel
Core chips.

But I'm also certain Apple wouldn't do that if Mac apps wouldn't be easily
ported to the ARM architecture. That's why I think Apple missed a big
opportunity to ensure any Mac Store app is cross-platform between x64 and
ARMv8 by default. But have they done anything recently under the hood that
could make that possible anyway in the future?

~~~
mikeash
I don't think there will be any advance signs. Nearly all of the CPU-specific
stuff is common between Mac OS X and iOS, since that's generally in the kernel
and low-level userspace libraries. The high-level stuff has been through
multiple architecture transitions in the past few years (PPC->i386->x86-64)
and any inadvertent architecture-specific assumptions in it has probably been
ferreted out by now.

Mac OS X is likely ready to go on ARM right now, with just a push of a button
to build it. I'd be utterly shocked if Apple weren't maintaining an ARM build
of OS X internally.

If and when Apple decides to make an ARM-based Mac, we will probably only know
it when it actually shows up, because the groundwork is fairly solid. The only
thing that's lacking is encouraging third-party developers to cross-compile,
and given Apple's famous secrecy, it's highly unlikely they'll give any
advance warning just for that.

------
wiremine
This sentence made me laugh a bit: "Finally, with the 64-bit A7, Apple has
made it possible for developers to take the 64-bit apps they’ve written for
the Mac and bring them to iOS 7 with relative ease."

I guess I missed the whole "we're port your Mac Apps to the iPhone" part of
the keynote.

~~~
Cookingboy
A lot of code are very sharable between OS X and iOS apps. Sure the UI layer
will be different, but many mid or low level libraries used for both iOS/OS X
cross-platform apps are shared between them, and having both platforms
supporting 64bit can open up that possibility even more.

~~~
wiremine
Yeah, I get that, I was just amused by the choice of "app" vs. "library".

------
jareds
How much battery in a phone is used for RAM? What will the limit be assuming
current incremental improvements in battery technology before it isn’t worth
adding more RAM? When I heard this the first thing I thought of is that we may
see an iPad with more than 4 gigs of memory since for video and audio editing
that extra memory could make a big difference and the battery to power the RAM
won’t be as big an issue in an iPad as in an iPhone.

~~~
keeperofdakeys
Battery technology hasn't really moved anywhere in the last five years (even
ten). So increasing battery capacity means a bigger battery.

As for RAM, I found a good paper.
[http://www.nicta.com.au/pub?doc=3587](http://www.nicta.com.au/pub?doc=3587)
If you go to the top of page 13, you'll see that RAM accounts for less than
about 5% of all power usage. Given that cpus and radios in modern smartphones
can use a bit more power, you're looking at even less. So I'd say ram is
negligible towards power usage, so the amount doesn't have a power constraint.

------
musesum
I've read that the NX (never execute) bit on some 64bit processors, may
prevent some buffer overflow attacks. I wonder if this is available for the
Apple A7 chip?

~~~
jasomill
Yes, it is, but this is not new for the A7; it's also available on (all?)
older iPhone CPUs. You're probably thinking about x86, where page-granular NX
wasn't available until AMD64.

------
Steko
Hey look another thread flagged down to oblivion by the we-hate-Apple HN
mafia. (Thread should be in top 10 atm by votes, is #80-something)

------
kdot
What are the chances of the iPhone 5S having 4GBs of RAM? iOS 7 is bringing
multitasking support, potentially making more RAM necessary.

~~~
masklinn
> What are the chances of the iPhone 5S having 4GBs of RAM?

None. Apple is not going to quadruple RAM from one generation to the next.

