There is still several million people out there with those devices or there might be some that might not transition to iOS 7 that has a model previous to the 5s.
In a month, AS THE ARTICLE STATES, the developer has the choice to support iOS6 32bit AND/OR iOS 7 32/64 bit from the same xCode kit.
In other words, don't blame Apple, blame the developer. This would be no different from a change in an API/SDK that is not in iOS6. The developer could decide not support those not upgrading, or they fork the code and build 2 apps… one for the left behinds, and one for the current state.
Technology marches onward. Every once and a while there is a HW change that drives developers to decide how to handle those that don't upgrade. This is one of those times. It appears (on the face… details may tell us otherwise) that apple has balanced technical secrecy and developer support as best as they could.
In a month, AS THE ARTICLE STATES, the developer has the choice to support iOS6 32bit AND/OR iOS 7 32/64 bit from the same xCode kit.
In other words, don't blame Apple, blame the developer. This would be no different from a change in an API/SDK that is not in iOS6. The developer could decide not support those not upgrading, or they fork the code and build 2 apps… one for the left behinds, and one for the current state.
Technology marches onward. Every once and a while there is a HW change that drives developers to decide how to handle those that don't upgrade. This is one of those times. It appears (on the face… details may tell us otherwise) that apple has balanced technical secrecy and developer support as best as they could.
They aren't saying that Developers should only do 32 bit, but Apple is telling these guys, do the 32/64 but if they just want to support iOS 6, which WILL fade away at whatever rate, to do 32 bit only, but they would be better off if they did 32/64, because in a year from now, the iPhone 5C will be the bottom end model and the 5S will be the second tier model as there will be a 6 which will have the A8 processor which will be faster this and better that. And then in two years from now, the 6 will be second tier, the 5S will be the bottom and the 7 will have the A9 processor which will be another incremental improvement in processor. So, two years from now, all iPhone models sold will be 64 bit and then over the course of a year or so, 32 bit will be completely gone. Same rules will apply to iPads.
But, the next line says that it will change next month. It doesn't sound like performance of 32 bit apps will be any worse than they are now, so Apple isn't in a rush. The 64bit performance boost will probably be more noticeable in future iPhones, when there's 4 GB of RAM in it. They're probably a few years ahead of the curve, rather than a month behind on the product launch.
The 4Gig argument is getting old. There are a metric crap ton of reasons for 64bit over the memory stuff. How about bigger single instructions, (doing more with one instruction vs 32bit). Faster to idle because of that, saving power, and accomplishing more faster. Those are just a few. There are a lot more. One of the only reasons the fingerprint sensor is so fast at reading and not slow like all of the rest of the previous ones on laptops and computers is because of the 64bit instruction set in iOS 7 and the A7's extra 64bit registers.
Keep in mind that the vast majority of the bulk of most apps
I love the vast majority of the bulk of most but not quite all of somewhat a bushel of around half of these kinds of sentences. Sorry, couldn't resist.
The 4Gig argument is getting old. There are a metric crap ton of reasons for 64bit over the memory stuff. How about bigger single instructions, (doing more with one instruction vs 32bit). Faster to idle because of that, saving power, and accomplishing more faster. Those are just a few. There are a lot more. One of the only reasons the fingerprint sensor is so fast at reading and not slow like all of the rest of the previous ones on laptops and computers is because of the 64bit instruction set in iOS 7 and the A7's extra 64bit registers.
Disclaimer: I'm not an electrical engineer. That said, I did look through that article. On page 1 it states the primary motivation for moving to 64 bits:
Quote:
One of the main motivations for ARMv8 was memory addressing. The existing architecture was limited to a 4GB virtual address space, which is an uncomfortable constraint for systems with 2GB or more physical memory. The first round of 64-bit extensions were developed in the 1990?s for server-oriented RISC families. In the early 2000?s, the client-centric x86 bumped into the same virtual memory limitations and was extended to x86-64. Now a decade after x86, ARM-based tablets routinely ship with 1-2GB of memory, approaching the practical limit.
Does the article discuss other major benefits of 64 bits? It seems that for non-memory constrained programs that don't do a lot of 64-bit arithmetic, the numerous other architectural improvements in ARMv8, not the 64 bit registers, would account for most of the performance increase.
One of the only reasons the fingerprint sensor is so fast at reading and not slow like all of the rest of the previous ones on laptops and computers is because of the 64bit instruction set in iOS 7 and the A7's extra 64bit registers.
Are you suggesting that the A7 with its extra registers is faster than desktop and laptop processors, which have been at 64 bit since the days of Pentium D and Athlon 64? Linux distributions were ported to amd64 long ago. Yet fingerprint readers didn't magically become faster under Linux. The speed of the fingerprint reader is constrained by the sensor, not by the available CPU power. The Authentec sensor is simply better compared to previous ones.
I'm wondering how Android will handle this shift, will apps be optimized or will it just be 64bit hardware marketed as the latest greatest but the software remains 32bit? Android fragmentation means they definitely need fat binaries, and what about Windows 8? Or Blackberry. Those last 2, as if they don't have enough problems Apple!?
I'm wondering how Android will handle this shift, will apps be optimized or will it just be 64bit hardware marketed as the latest greatest but the software remains 32bit? Android fragmentation means they definitely need fat binaries, and what about Windows 8? Or Blackberry. Those last 2, as if they don't have enough problems Apple!?
64-bit java has been around a long time as have 64-bit linux kernels. I don't think the Android OS shift to 64-bits is as difficult as you think. I don't know where you're getting the fat binaries from. Java 64-bit apks are going to be about as bloated as IOS 64-bit apps, which is very little. There will likely be 64 bit versions and 32 bit versions of apps, just like on IOS. In addition java byte code is platform independent the same application compiled under 32bit javac will work perfectly fine on a 64bit processor. The main effort is porting the jvm and any native interfaces
Disclaimer: I'm not an electrical engineer. That said, I did look through that article. On page 1 it states the primary motivation for moving to 64 bits:
Does the article discuss other major benefits of 64 bits? It seems that for non-memory constrained programs that don't do a lot of 64-bit arithmetic, the numerous other architectural improvements in ARMv8, not the 64 bit registers, would account for most of the performance increase.
There is the quote from the article you've seams to deliberately step over it:
Quote:
Last year, ARM announced the 64-bit ARMv8 for Application processors. The new architecture is elegant, backwards compatible, and removes several crufty features from the existing ARMv7
There is the quote from the article you've seams to deliberately step over it:
Is the removal of those "crufty features" related to the 64 bit transition? We were discussing specifically the benefits of 64 bits vs 32 bit, not the numerous other improvements. I mean, x86-64 CPUs have various improvements over the earlier x86 processors. The core 2 duo will run programs much faster than a pentium 4 would. But if you run two versions of the same program on the same x86-64 cpu, the only difference being the build target, you won't see much of a performance difference unless your program uses a lot of 64 bit arithmetic. For instance, if you run numerical simulations on the same CPU with both the 32-bit and 64-bit builds of Matlab, the 64-bit build will tend to run a bit faster. But 32 bit matlab on a Core i7 will definitely outperform 64 bit matlab on a Core 2, because the other architectural improvements of the Core i series matter much more.
Is the removal of those "crufty features" related to the 64 bit transition? We were discussing specifically the benefits of 64 bits vs 32 bit, not the numerous other improvements. I mean, x86-64 CPUs have various improvements over the earlier x86 processors. The core 2 duo will run programs much faster than a pentium 4 would. But if you run two versions of the same program on the same x86-64 cpu, the only difference being the build target, you won't see much of a performance difference unless your program uses a lot of 64 bit arithmetic. For instance, if you run numerical simulations on the same CPU with both the 32-bit and 64-bit builds of Matlab, the 64-bit build will tend to run a bit faster. But 32 bit matlab on a Core i7 will definitely outperform 64 bit matlab on a Core 2, because the other architectural improvements of the Core i series matter much more.
I do consider any major architecture changes imply with the new ARM AArch64 as related to new generation transition. Just like the G5 or x86-64 CPU before, the A7 have numerous internal improvement over the earlier ARMv7 architecture beneficial to already existing Apps, which is explained in great detail in the article. Beside why are you narrowing your mind on numerical simulation who have much less to do with CPU than FPU? You know common usage for CPU is acting as an "Data Pump" to move big chunk of Data between I/Os, having more and bigger registers greatly improve performance with great efficiency
I do consider any major architecture changes imply with the new ARM AArch64 as related to new generation transition. Just like the G5 or x86-64 CPU before, the A7 have numerous internal improvement over the earlier ARMv7 architecture beneficial to already existing Apps, which is explained in great detail in the article. Beside why are you narrowing your mind on numerical simulation who have much less to do with CPU than FPU? You know common usage for CPU is acting as an "Data Pump" to move big chunk of Data between I/Os, having more and bigger registers greatly improve performance with great efficiency
I stand corrected. ARMv8 bundles most of its improvements with the A64 instruction set. A32 is there for backward compatibility, but a program has to be built for A64 to reap most of the performance improvements.
I stand corrected. ARMv8 bundles most of its improvements with the A64 instruction set. A32 is there for backward compatibility, but a program has to be built for A64 to reap most of the performance improvements.
I agree, programs need to be built for AArch64 to get most of the new improvements. Still older apps should gain better benefit from the new ARMv8 architecture than going the Samsung way of adding more cores.
Comments
There is still several million people out there with those devices or there might be some that might not transition to iOS 7 that has a model previous to the 5s.
In a month, AS THE ARTICLE STATES, the developer has the choice to support iOS6 32bit AND/OR iOS 7 32/64 bit from the same xCode kit.
In other words, don't blame Apple, blame the developer. This would be no different from a change in an API/SDK that is not in iOS6. The developer could decide not support those not upgrading, or they fork the code and build 2 apps… one for the left behinds, and one for the current state.
Technology marches onward. Every once and a while there is a HW change that drives developers to decide how to handle those that don't upgrade. This is one of those times. It appears (on the face… details may tell us otherwise) that apple has balanced technical secrecy and developer support as best as they could.
In a month, AS THE ARTICLE STATES, the developer has the choice to support iOS6 32bit AND/OR iOS 7 32/64 bit from the same xCode kit.
In other words, don't blame Apple, blame the developer. This would be no different from a change in an API/SDK that is not in iOS6. The developer could decide not support those not upgrading, or they fork the code and build 2 apps… one for the left behinds, and one for the current state.
Technology marches onward. Every once and a while there is a HW change that drives developers to decide how to handle those that don't upgrade. This is one of those times. It appears (on the face… details may tell us otherwise) that apple has balanced technical secrecy and developer support as best as they could.
They aren't saying that Developers should only do 32 bit, but Apple is telling these guys, do the 32/64 but if they just want to support iOS 6, which WILL fade away at whatever rate, to do 32 bit only, but they would be better off if they did 32/64, because in a year from now, the iPhone 5C will be the bottom end model and the 5S will be the second tier model as there will be a 6 which will have the A8 processor which will be faster this and better that. And then in two years from now, the 6 will be second tier, the 5S will be the bottom and the 7 will have the A9 processor which will be another incremental improvement in processor. So, two years from now, all iPhone models sold will be 64 bit and then over the course of a year or so, 32 bit will be completely gone. Same rules will apply to iPads.
I'd say at least 90% of iOS users will be on iOS7 by the end of the year. Not an issue.
Agreed, adoption rate for iOS is phenomenal, to say the least. 6 is at 98% right now.
But, the next line says that it will change next month. It doesn't sound like performance of 32 bit apps will be any worse than they are now, so Apple isn't in a rush. The 64bit performance boost will probably be more noticeable in future iPhones, when there's 4 GB of RAM in it. They're probably a few years ahead of the curve, rather than a month behind on the product launch.
The 4Gig argument is getting old. There are a metric crap ton of reasons for 64bit over the memory stuff. How about bigger single instructions, (doing more with one instruction vs 32bit). Faster to idle because of that, saving power, and accomplishing more faster. Those are just a few. There are a lot more. One of the only reasons the fingerprint sensor is so fast at reading and not slow like all of the rest of the previous ones on laptops and computers is because of the 64bit instruction set in iOS 7 and the A7's extra 64bit registers.
Keep in mind that the vast majority of the bulk of most apps
I love the vast majority of the bulk of most but not quite all of somewhat a bushel of around half of these kinds of sentences. Sorry, couldn't resist.
The 4Gig argument is getting old. There are a metric crap ton of reasons for 64bit over the memory stuff. How about bigger single instructions, (doing more with one instruction vs 32bit). Faster to idle because of that, saving power, and accomplishing more faster. Those are just a few. There are a lot more. One of the only reasons the fingerprint sensor is so fast at reading and not slow like all of the rest of the previous ones on laptops and computers is because of the 64bit instruction set in iOS 7 and the A7's extra 64bit registers.
Does the article discuss other major benefits of 64 bits? It seems that for non-memory constrained programs that don't do a lot of 64-bit arithmetic, the numerous other architectural improvements in ARMv8, not the 64 bit registers, would account for most of the performance increase.
One of the only reasons the fingerprint sensor is so fast at reading and not slow like all of the rest of the previous ones on laptops and computers is because of the 64bit instruction set in iOS 7 and the A7's extra 64bit registers.
Are you suggesting that the A7 with its extra registers is faster than desktop and laptop processors, which have been at 64 bit since the days of Pentium D and Athlon 64? Linux distributions were ported to amd64 long ago. Yet fingerprint readers didn't magically become faster under Linux. The speed of the fingerprint reader is constrained by the sensor, not by the available CPU power. The Authentec sensor is simply better compared to previous ones.
I'm wondering how Android will handle this shift, will apps be optimized or will it just be 64bit hardware marketed as the latest greatest but the software remains 32bit? Android fragmentation means they definitely need fat binaries, and what about Windows 8? Or Blackberry. Those last 2, as if they don't have enough problems Apple!?
I'm wondering how Android will handle this shift, will apps be optimized or will it just be 64bit hardware marketed as the latest greatest but the software remains 32bit? Android fragmentation means they definitely need fat binaries, and what about Windows 8? Or Blackberry. Those last 2, as if they don't have enough problems Apple!?
64-bit java has been around a long time as have 64-bit linux kernels. I don't think the Android OS shift to 64-bits is as difficult as you think. I don't know where you're getting the fat binaries from. Java 64-bit apks are going to be about as bloated as IOS 64-bit apps, which is very little. There will likely be 64 bit versions and 32 bit versions of apps, just like on IOS.
In addition java byte code is platform independent the same application compiled under 32bit javac will work perfectly fine on a 64bit processor. The main effort is porting the jvm and any native interfaces
There is the quote from the article you've seams to deliberately step over it:
There is the quote from the article you've seams to deliberately step over it:
Is the removal of those "crufty features" related to the 64 bit transition? We were discussing specifically the benefits of 64 bits vs 32 bit, not the numerous other improvements. I mean, x86-64 CPUs have various improvements over the earlier x86 processors. The core 2 duo will run programs much faster than a pentium 4 would. But if you run two versions of the same program on the same x86-64 cpu, the only difference being the build target, you won't see much of a performance difference unless your program uses a lot of 64 bit arithmetic. For instance, if you run numerical simulations on the same CPU with both the 32-bit and 64-bit builds of Matlab, the 64-bit build will tend to run a bit faster. But 32 bit matlab on a Core i7 will definitely outperform 64 bit matlab on a Core 2, because the other architectural improvements of the Core i series matter much more.
Is the removal of those "crufty features" related to the 64 bit transition? We were discussing specifically the benefits of 64 bits vs 32 bit, not the numerous other improvements. I mean, x86-64 CPUs have various improvements over the earlier x86 processors. The core 2 duo will run programs much faster than a pentium 4 would. But if you run two versions of the same program on the same x86-64 cpu, the only difference being the build target, you won't see much of a performance difference unless your program uses a lot of 64 bit arithmetic. For instance, if you run numerical simulations on the same CPU with both the 32-bit and 64-bit builds of Matlab, the 64-bit build will tend to run a bit faster. But 32 bit matlab on a Core i7 will definitely outperform 64 bit matlab on a Core 2, because the other architectural improvements of the Core i series matter much more.
I do consider any major architecture changes imply with the new ARM AArch64 as related to new generation transition. Just like the G5 or x86-64 CPU before, the A7 have numerous internal improvement over the earlier ARMv7 architecture beneficial to already existing Apps, which is explained in great detail in the article. Beside why are you narrowing your mind on numerical simulation who have much less to do with CPU than FPU? You know common usage for CPU is acting as an "Data Pump" to move big chunk of Data between I/Os, having more and bigger registers greatly improve performance with great efficiency
I do consider any major architecture changes imply with the new ARM AArch64 as related to new generation transition. Just like the G5 or x86-64 CPU before, the A7 have numerous internal improvement over the earlier ARMv7 architecture beneficial to already existing Apps, which is explained in great detail in the article. Beside why are you narrowing your mind on numerical simulation who have much less to do with CPU than FPU? You know common usage for CPU is acting as an "Data Pump" to move big chunk of Data between I/Os, having more and bigger registers greatly improve performance with great efficiency
I stand corrected. ARMv8 bundles most of its improvements with the A64 instruction set. A32 is there for backward compatibility, but a program has to be built for A64 to reap most of the performance improvements.
I stand corrected. ARMv8 bundles most of its improvements with the A64 instruction set. A32 is there for backward compatibility, but a program has to be built for A64 to reap most of the performance improvements.
I agree, programs need to be built for AArch64 to get most of the new improvements. Still older apps should gain better benefit from the new ARMv8 architecture than going the Samsung way of adding more cores.