[IvyMike]

> What do you mean by "a phone?"

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.

[stephencanon]

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

[IvyMike]

OK, let me state it without a metaphor: there is a tradeoff to be made when you optimize for raw horsepower no matter what the domain.

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.

[gfodor]

i really hope i don't need to explain why this is a beyond terrible car analogy argument. do you have a better way to explain why a 64-bit chip is overkill for a phone? is 2013 iPhone hardware overkill for a "phone" because it is 20x more powerful than the first iPhone? 640k should be enough for everyone, and all that.

[IvyMike]

The car analogy was just a way to bring up the generic engineering principle that "everything is a tradeoff".

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.

[gfodor]

I think one thing most commentators are missing re: 64-bit in the 5S is that Apple is not putting the 64-bit processor in there for phones today, but for phones tomorrow. The 5S, as they state, is its "forward looking" platform. If you want a phone that optimizes things differently, look to the 5C. The 5S is there so the compiler, app developers, and the overall ecosystem move to 64-bit and get the kinks out earlier rather than later.

[IvyMike]

> The 5S is there so the compiler, app developers, and the overall ecosystem move to 64-bit and get the kinks out earlier rather than later.

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.