Apple's Massive Missed Opprotunity

[Carlanga]

... Any 64bit apps developed will not be backwards compatible with older phones. By phasing these updates, they are creating fragmentation for developers. Next year, assuming they do go with higher density screens, a developer will have to maintain a 32bit 480p app, a 32bit 720p app, a 64bit 720p app, and a 64bit 1080p (or whatever resolution they choose) app.

woosh over your head I see

 

[leman]

Ok, I almost choked reading this. First, understand the number of registers has nothing to do with 32-bit vs 64-bit. So your examples show the benefits of an architecture with more registers, which a compiler can optimize even a 32-bit application for.

So unless Apple is purposely gimping their compiler I can gain the same benefit of more registers without 64-bit.

Wow, you are really a tough nut. Let me quote Apple for you

Among other architecture improvements, a 64-bit ARM processor includes twice as many integer and floating-point registers as earlier processors do. As a result, 64-bit apps can work with more data at once for improved performance.

Nobody is gimping the compiler, the 32-bit instructions set simply has LESS registers than the 64-bit one. Its the same for Intel CPUs btw. The x86 instruction set defines 8 general-purpose registers while the x86-64 instruction set doubles it to 16.

So yeah, back to school for you

 

[leman]

Sure. But I'm sure they spent months getting the game ready for 64 bit.

----------



There's really no "clean manner" to develop a game for both systems that easily. Otherwise you would end up with a highly inefficient game.

Amazing, a thread full of experts on algorithms and CPU architectures Would you please enlighten us why a trivial thing like doubling the width of your words would have such a huge impact that you have to rewrite your code? Does your game rely on that much integer math that going from 32 bit long to a 64 bit one would make such a whopping difference for you? Because I don't see anything else which would require much porting work. Oh, sure, hand-written assembly. But how many people are doing that nowadays?

BTW, by clean manner I mean not mixing types, not relying on platform-specific 'magic' (too much), not performing unsafe casts - things like that. Should be obvious to any competent programmer.

P.S. Stuff I write somehow 'magically' compiles for 32 bit and 64 bit Windows, Li nut and OS X - and they include custom memory allocation and lots of pointer trickery. I wonder why its so simple. Maybe because I don't use 'long', instead relying on C99 types and do not rely on particular word length but use sizeof() instead, again - like everybody should.

 

[Kurso]

Wow, you are really a tough nut. Let me quote Apple for you



Nobody is gimping the compiler, the 32-bit instructions set simply has LESS registers than the 64-bit one. Its the same for Intel CPUs btw. The x86 instruction set defines 8 general-purpose registers while the x86-64 instruction set doubles it to 16.

So yeah, back to school for you

Are you trying to imply we don't extend instruction sets unless we extend register length? Registers and instructions are added all the time. Compilers are optimized for those new registers all the time. This is not a concept tied to a 64-bit transition.

 

[BaldiMac]

Sure. But I'm sure they spent months getting the game ready for 64 bit.

Nope.

 

[leman]

Are you trying to imply we don't extend instruction sets unless we extend register length? Registers and instructions are added all the time. Compilers are optimized for those new registers all the time. This is not a concept tied to a 64-bit transition.

Amazing :roll eyes: How stubborn can a person get?

I am not implying anything. I am just stating a FACT. The A64 instruction set used in the iPhone 5S in the 64bit mode exposes more registers then its 32 bit ARM instruction set. And this is where potential performance win comes from. You can't access these registers from 32bit code because there is no 32 bit machine code to do this. And the reason for that the 64 bit ARM uses a different instruction encoding. The information is available online. Again: educate yourself before you write.

 

[Gincoma]

sorry to break up the pissing match but anyone with a 32 bit phone at some point will be forced to get a 64 bit phone with all developers devloping apps in 64 bit format? im bit confused and trying to understand the 64 bit vs 32 bit and what that means to everyone owning a 32 bit phone?

 

[Kurso]

Amazing :roll eyes: How stubborn can a person get?

I am not implying anything. I am just stating a FACT. The A64 instruction set used in the iPhone 5S in the 64bit mode exposes more registers then its 32 bit ARM instruction set. And this is where potential performance win comes from. You can't access these registers from 32bit code because there is no 32 bit machine code to do this. And the reason for that the 64 bit ARM uses a different instruction encoding. The information is available online. Again: educate yourself before you write.

But this has nothing to do with 64-bit!!!! What do you not get about that? They could add 1024 registers and call them ALotOInstruction instruction set. The compiler can still optimize for it. That is nothing more than optimizing for the number of registers NOT optimizing for 64-bit. This happens all the time in CPUs and compilers with new instructions such as the SSE set or AES.

In fact if ARM doubled the number of registers 32-bit registers and created a set of instructions called A32-2 the compiler could optimize for this and you would get THE EXACT SAME performance increase! Do you understand now? It has nothing to do with 64-bit!

Optimizing for 64-bit is about memory management, proper resource allocation and optimized computation in your OS, framework and app.

 

[leman]

But this has nothing to do with 64-bit!!!! What do you not get about that? They could add 1024 registers and call them ALotOInstruction instruction set. The compiler can still optimize for it. That is nothing more than optimizing for the number of registers NOT optimizing for 64-bit. This happens all the time in CPUs and compilers with new instructions such as the SSE set or AES.

It has EVERYTHING to do with 64bit CPU because its a feature of the 64bit CPU. As the reality stands, you can't have this extended register set without compiling for the 64bit CPU. In regards to SSE and the like - I hope you realise the difference between general-purpose registers and additional specialised registers? Show me an architecture that makes a habit of extending the general-purpose register set? Do you realise what mess it would mean for software compatibility?

In fact if ARM doubled the number of registers 32-bit registers and created a set of instructions called A32-2 the compiler could optimize for this and you would get THE EXACT SAME performance increase! Do you understand now? It has nothing to do with 64-bit!

Sure. But they didn't. Instead they built the extended register set into the 64-bit instruction set. Whats so difficult to understand about that?

Optimizing for 64-bit is about memory management, proper resource allocation and optimized computation in your OS, framework and app.

This is BS. You don't need any different memory management with 64-bit code, unless you are overusing pointer-heavy data structures. The optimal resource allocation strategies are the same for both 32 bit and 64 bit code. Optimised 64-bit computation would only apply to heavy integer computation - which is of very limited utility to most applications. Same for hand-coded assembly. The main performance benefit of the 64-bit CPU comes from the new instructions with more registers and wider SIMD registers (which again do not require any specific optimisations because the compiler and or math framework will do it for you). So the fact is - simply compiling you application to the 64 bit instruction set is very likely to give your code a healthy performance boost. The 64-bit specific code paths are of very niche utility and generally not required.

I am out of this now. I take no pleasure in talking to someone who go out of their way to appear dense.

 

[Kurso]

It has EVERYTHING to do with 64bit CPU because its a feature of the 64bit CPU. As the reality stands, you can't have this extended register set without compiling for the 64bit CPU. In regards to SSE and the like - I hope you realise the difference between general-purpose registers and additional specialised registers? Show me an architecture that makes a habit of extending the general-purpose register set? Do you realise what mess it would mean for software compatibility?

No, The CPU has more registers and it happens to be 64-bit. Correlation vs causality. Do you understand the fundamental difference? And we deal with this all the time, being able to compile for different instruction sets (including those tied to GPRs) from the same compiler. Just take a look at the mess of GCC options...

And the real question is do you know the difference in regards to extensions because some extensions provide GRPs that may be more or less optimal to use for a given operation.

Sure. But they didn't. Instead they built the extended register set into the 64-bit instruction set. Whats so difficult to understand about that?

It is not difficult to understand. Once again, the instruction set provides access to more registers, and it happens to be 64-bit.

This is BS. You don't need any different memory management with 64-bit code, unless you are overusing pointer-heavy data structures. The optimal resource allocation strategies are the same for both 32 bit and 64 bit code. Optimised 64-bit computation would only apply to heavy integer computation - which is of very limited utility to most applications. Same for hand-coded assembly. The main performance benefit of the 64-bit CPU comes from the new instructions with more registers and wider SIMD registers (which again do not require any specific optimisations because the compiler and or math framework will do it for you). So the fact is - simply compiling you application to the 64 bit instruction set is very likely to give your code a healthy performance boost. The 64-bit specific code paths are of very niche utility and generally not required.

I am out of this now. I take no pleasure in talking to someone who go out of their way to appear dense.

Even Apples own guidance agrees with me... In fact a poorly written app can take a huge hit in performance simply recompiling for 64-bit without optimizing for it.

Apple agrees with me, and anyone else that has made the transition from 32 to 64-bit for that matter (Just do a little digging and you will see). You don't have to.

----------

sorry to break up the pissing match but anyone with a 32 bit phone at some point will be forced to get a 64 bit phone with all developers devloping apps in 64 bit format? im bit confused and trying to understand the 64 bit vs 32 bit and what that means to everyone owning a 32 bit phone?

My guess is at some point Apple will make a version of iOS (iOS 9 maybe) 64-bit only and not support it on anything lower than the iPhone 5s. So 32-bit compatibility will be assured until then. Nothing to worry about.