
Qualcomm backtracks from Apple A7 marketing gimmick comments - kposehn
http://www.techhive.com/article/2053200/qualcomm-backtracks-from-apple-a7-marketing-gimmick-comments.html
======
mgraczyk
Nobody seems to be saying this here so I'll just come out and say it...

Qualcomm's knee jerk reaction to press that praises Apple's platform is to
point out the obviously premature move to 64 bit mobile chips, since Apple
does not buy Qcomm SOCs and competes with Samsung, Qcomm's biggest customer.
After a little critical thinking, Qualcomm realizes that it too will shortly
be selling 64 bit mobile chips because now Samsung will want to match apple
spec for spec, as most Android OEMs typically do.

\--------------------------- As whether the move was a "gimmick" or not: The
move to 64 bit would have been premature if Microsoft or an Android OEM had
done it, but Apple made the right call for a few reasons:

(the obvious) - ARM v8 is a new ISA, and porting 32-bit ARM kernel code to the
new ISA just to abandon it in a few years would be foolish

(musing)- Apple's OS people now only have to worry about one kernel code base
when writing non-assembly, non performance critical code.

(speculation) - Apple may consider switching some of their traditionally x86
lineup to use lower power ARM chips in the intermediate future (2-4 years) and
is giving itself that option by getting their kernel ready for ARM 64.

(way out there) - Apple may be planning to use their mobile chips in ultra low
power server clusters, and they had to port the kernel to 64 bit before that
was an option.

~~~
masklinn
In "the obvious", note that the switch to ARM64 also allows a more efficient
Obj-C runtime: there are more unused bits (due to alignment and effective
pointer sizes) in AArch64 than in AArch32, and more in ARM64 than x86-64.

This allows the obj-c runtime to smuggle significantly more information inline
in the `isa` pointer on ARM64 than on ARM32 or x86-64 (via pointer tagging):
[http://www.sealiesoftware.com/blog/archive/2013/09/24/objc_e...](http://www.sealiesoftware.com/blog/archive/2013/09/24/objc_explain_Non-
pointer_isa.html) [http://www.mikeash.com/pyblog/friday-
qa-2013-09-27-arm64-and...](http://www.mikeash.com/pyblog/friday-
qa-2013-09-27-arm64-and-you.html)

(amongst other things, _19_ bits of the pointer are now used to hold the
object's reference count, for any object with less than half a million
references an incref or decref is just an atomic increment or decrement of
this field, instead of an indirection through a global refcount table with a
bunch of locks involved)

~~~
sorbits
> In "the obvious", note that the switch to ARM64 also allows a more efficient
> Obj-C runtime […]

Why wouldn’t inline reference counts (as an extra 32 bit word in the object
struct) be just as effective on a 32 bit architecture?

Apple’s tagged pointer tricks are just making the best of a bad situation.

~~~
r00fus
How are extra 32bit words considered "inline"? Wouldn't this completely miss
using the register for count evaluation?

------
mistercow
That wasn't a very useful article in terms of explaining the potential
benefits of 64-bit on mobile. I get that the reasons are a bit esoteric; "a
larger address space makes ASLR more effective" is tough to explain to a non-
programmer reader. But a writer's job is to get people who understand to
explain and then write that explanation in a way that readers can roughly
understand.

~~~
hclee
Agree. Going 64-bits in general can benefit that more instruction sets, more
data sets per instruction, memory access at repeating process. What's in this
article is just quote by CMO that is a claim without benchmark evidence or
whatever.

------
smoyer
Unnamed sources at the company said that Anand Chandrasekher would be
receiving a well-deserved spanking.

~~~
interstitial
As long as the spankings remain within the "Chandrasekher Limit" I don't think
we are in danger of dwarfing the larger issues.

------
hendzen
Gruber must be feeling pretty smug right now:
[http://daringfireball.net/linked/2013/10/02/qualcomm-a7](http://daringfireball.net/linked/2013/10/02/qualcomm-a7)

~~~
alanfalcon
Yep:
[http://daringfireball.net/linked/2013/10/08/qualcomm](http://daringfireball.net/linked/2013/10/08/qualcomm)

------
jjm
"...for compatibility reasons, we still support the entire ARMv7 machine in
the new ARMv8 architecture, but when running 64-bit software, this part of the
machine is not being used, and the area of complex legacy it had built up does
not need to be active when running in the 64-bit ISA, unlike other
architectures where 64-bit extension was simply added to the historical
complexity and legacy of their 32-bit mode. The new ISA drew upon the years of
experience of building different micro architecture implementations, so again
it was defined so that these new processors can be more easily optimized for
low power operation — an opportunity not really offered since the first ARMv4
machine that resulted in the now legendary low power ARM7 processors."

[http://www.arm.com/files/downloads/ARMv8_white_paper_v5.pdf](http://www.arm.com/files/downloads/ARMv8_white_paper_v5.pdf)

------
general_failure
That was a terrible comment from Anand Chandrasekher and shows fundamental
lack of understanding. How did he become the CMO?

------
TorKlingberg
Qualcomm supplies the modem/baseband chips in iPhones (at least the iPhone 4
and 5), so I imagine they wouldn't want to upset a customer too much.

------
ZoFreX
> A benefit of 64-bit is the ability to put more than 4GB of memory in
> smartphones

This is an annoying piece of misinformation that always rears its ugly head in
64-bit discussions. There are many ways to address more than 4GB of memory,
going 64-bit is far from the only option.

~~~
adestefan
True, but they're usually far from the most elegant or speedy option.

------
glasshead969
64bit move comes along with ARM v8 move. It wouldn't make sense for apple to
move to ARM v8 staying at 32bit. As far as I remember apple hasn't said that
2x performance improvement came from just 64bit. They included new ISA and
64bit compatible iOS 7 too.

~~~
Symmetry
Well, there _are_ actually some reasons to stay with 32 bit when using AArch64
in ARM v8. There are lots of goodies in the new, RISCier encodings and the
benefits from the more traditional encoding are more relevant for lower-end
chips. I'm sort of waiting for someone to make an ARM equivalent of the x32
ABI[1], using the new instructions but keeping 32-bit pointers to minimize
cache pressure.

Still, 64-bit memory addressing does have advantages in terms of garbage
collection, mmaping files, etc even if the phone has less than 1 GB of RAM.

[1][http://en.wikipedia.org/wiki/X32_ABI](http://en.wikipedia.org/wiki/X32_ABI)

------
swamp40
Lessons from my father: _Shit_ is best eaten in small bites, as it is served.

------
mukundmr
Zero credibility all around. I hope to see some proper details on how exactly
this helps mobile applications.

~~~
micampe
[http://www.mikeash.com/pyblog/friday-
qa-2013-09-27-arm64-and...](http://www.mikeash.com/pyblog/friday-
qa-2013-09-27-arm64-and-you.html)

~~~
mirsadm
From the conclusion: The simple fact of moving to 64-bit does little. It makes
for slightly faster computations in some cases, somewhat higher memory usage
for most programs, and makes certain programming techniques more viable.
Overall, it's not hugely significant.

So it isn't a huge deal. It's the overall package that adds up to a much
faster SOC.

~~~
mturmon
(I see the author of the piece you quoted has responded also.)

Really, it's not just the SOC.

As described in @mikeash's piece, the 64-bit address length has allowed Apple
to inline some per-object information (like reference counts) with object
pointers, which is a big win in some key operations (2x faster object
creation/destruction), which could sometimes make a big difference at the
application level.

