Can anyone explain to me why being 64 bit matters on a phone?
For example adding 64-bit numbers; finding the end of zero-terminated strings; certain hashing and encryption operations; and so on.
It's also good marketing, of course.
14 registers is pretty tight. 31 registers are better, and doubling the width helps for structure locals and parameters (which Clang/LLVM fortunately does a good job of keeping in registers). (I do a lot of work on a processor 60-odd 64-bit registers, and even then GCC decides to spill registers now and then.)
https://mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-yo...
How about a device with "physical memory of 1 or 2GB and tight power constraints"?
To quote the article, "the new 64-bit A7 chip is the smartphone equivalent of a big V12 engine." Sure, but there's a reason why you don't drive a car with a V12 engine, too.
Fortunately, phones are not cars, and engineers don't make design decisions on the basis of strained or completely bogus metaphors.
So as far as "do 64-bit processors have tradeoffs that are not worth it in current cell phones", I think it's still a fair question.
It's been said many other times elsewhere in the comments, but to summarize:
1) One of the biggest benefits of a 64-bit processor is the ability to address a gigantic memory space. Phones just don't have that much memory today.
2) Even if they did, the types of processes that are run on phones usually aren't the kind that need that much memory. "Isn't that just 640k is enough for everyone"? Sure, but memory isn't free--if nothing else, a larger DRAM burns more power. So if you want to run a 8GB SQL server on your phone, it's going to cost you in terms of battery life.
3) Another big downside of a 64-bit process is that pointers are twice as large. So your 64-bit process actually consumes more memory than a 32-bit process; in programs with pointer-heavy data structures (like, say, trees) this can result in the 32-bit process being able to solve bigger problems than the 32-bit process. I have seen this in the embedded world when we moved a piece of network equipment from a 32-bit processor to a 64-bit processor. We doubled the memory but that only increased the solvable problem size by about 1.4.
4) Additionally, 64-bit process will tend to blow out your caches a lot faster.
5) If you've got a large data set that you'd like to plow through "big chunk" at a time, going to 64-bits at a time might be a win. But a 32-bit processor with vector instructions is usually quite good, too.
6) Does that 64-bit processor have more transistors? Probably. Does that mean it burns more power? Probably.
There are a lot of good things about that 64-bit processor that I am not mentioning, but the point is they are not free. A lot of these tradeoffs are hard to measure by outsiders because they didn't just change one variable: in this case, the move to 64-bit introduced new instructions, more registers, was concurrent with a smaller and faster transistor size, bigger caches, etc, etc.
It's important to consider what you could have done otherwise. Possibly you could have had a 32-bit processor with more cores. Possibly you could have had similar performance with more battery life. Possibly you could have had a lot of things, but if you just think "64 is bigger than 32 and therefore better" you will miss those possibilities.
This is a good point, and it's the first time I'm hearing it stated so succinctly.
With 64 bit mainstream chips, the manufacturers got to roll them out slowly, first to the scientific computing community and then into server applications before finally tackling widespread desktop adoption. Given that there's not an equivalent path in the mobile space, I guess you have to test the waters somewhere.