EDIT: Does the new iPhone even have 2GB of addressable memory? Does it benefit from the 64-bit address space at all? Apple's specs don't say how much RAM the thing has, and whether it has any VRAM. What else would the address space be used for? I imagine you could map the whole internal flash to memory, but that seems like an incredibly awful idea to me unless you want random addressing errors to corrupt storage (maybe it'd be fine if only ring 0 had access)
Even back in 2009 the guys at ID software were running into this due to the low limits how much you could memory map. There's a short blurb about it here: http://www.bethblog.com/2010/10/29/john-carmack-discusses-ra...
Between already mapped in shared libraries, files, VMA fragmentation 32bit address space is crowded.
EDIT: However, RAGE style textures do not really benefit in any way from the CPU being 64-bit. They benefit from virtualization of textures, which is usually done on the GPU - and in fact I believe there are OpenGL extensions that offer the ability to create a large 'virtual' texture that is not resident in video memory. So I don't actually believe that 64-bit address space is any better for RAGE (especially because random stalls from disk paging of textures are not something a game developer would tolerate).
However, I should note that compressed textures don't really come into the picture. You're not going to map a compressed texture into memory such that you access uncompressed pixels by reading/writing at a given address with compression happening behind the scenes - at least, I've never seen a real world shipped scheme for that in graphics. (I think the XBox 360's memory controller might have done something like that for compressed audio, though...)
EDIT 2: See this talk by id and nvidia that explains how virtual textures in RAGE are applied:
Note that instead of the kind of stall you'd get when paging data from disk to memory, the optimal behavior is that it uses blurry 'low resolution' data until high resolution pages are available. Totally different than 64-bit virtual memory you use on a CPU.
My main question is whether it would actually be realistic to do that kind of demand paging in most use cases. Do you really have the ability to create your own fault handlers in user mode? Otherwise, all you can do is page data in from disk, which is just that 'map storage into memory' use case I mentioned earlier.
Reduced fragmentation is a plus but getting it at the cost of doubling every pointer's size is not necessarily a huge win.
They added more registers and cleaned up some cruft in the 64-bit ISA, so that is where the speed is coming from. You also get some speed from the extra bits even if you aren't addressing 4+ GB of memory (e.g. 64 bit longs are native).
It doesn't make much sense to clean up the architecture without adding 64-bit at the same time. X86 -> X64 followed the same path.
Do 64-bit machine words actually speed things up on average? I would really assume that if an application is designed around 32-bit integers, doubling the size of every register is just going to waste resources.
The new Samsung Galaxy Note 3 has 3GB.
The bottom line point is that Apple delivered on the peformance front.
... working in conjunction with Samsung's new 28nm processes.
Furthermore, it's repurposing an EXISTING label (64-bit has an established meaning for desktop CPUs) to mean something else. I think that's silly.