No, I made no comment as to that. Try again without putting words in others’ mouths.
Yes you have, you said my comment about the address bus was incorrect and then when I proved you wrong you asked "well why does the 64 bit compiled apps show an increase of up to 25%?"
Quote:
Originally Posted by SolipsismX
No, no you didn't. You discredited everything that comes with AArch64 and made sweeping ignorant generalizations and even made foolish comments about RAM capacity and CPU bitness.
PS: I checked your posts. You didn't use ISA, AArch64, or the colloquial ARM64 once in your comments.
Huh? Why would I need to use those phrases, words when I can just say 64 bit or A7 when talking about the iphone 5s or ipad air? What else could I possibly be talking about? Is it really that difficult for you to realize that when talking about the A7 you are also talking about ARM64?
None of it was foolish.
Quote:
Originally Posted by SolipsismX
Did you know you're incorrectly equating the number of bits with the address bus with number of bits used in other parts of the system.
Right, that is why I repeatedly pointed out that large data array software can take advantage of the 64 bit regardless of the address bus.
Quote:
Originally Posted by Mechanic
yes he has. He overlooks that AArch64 doubled the number of registers over 32bit ARM. 32-bit ARM provides 16 integer registers, of which one is a dedicated program counter, two more are give over to a stack pointer and link register, and the other 13 are available for general use. With AArch 64 there are 32 integer registers, with a dedicated zero register, dedicated link register and dedicated frame pointer register. One further register is dedicated to the platform leaving 28 general purpose registers.
AArch 64 also increases the number of floating point registers as well. AArch 32 has 32 32 bit floating point registers. Which can overlap into various sized of floating points as needed. AArch 64 simplifies this and has 32 128 bit floating point registers that can be used for smaller amounts of data, but are dedicated and do not overlap which is a big performance win. With AArch 64 Physical RAM address size is decouple from CPU fitness.Data Bus size the amount of data fetched from RAM is likewise decoupled. A CPU instruction may request a certain size of data but the amount can be independentlycontrolled by either fetching in smaller amounts or fetching more than is necessary.Also a revised and streamlined the instruction set for a big performance gain. Also apple took advantage of AArch64 in a big way with an inline retain count, which eliminates the need to perform costly hash table lookup for retain and release operations in the common case. Those operations are very common in most Objective-C code and is a big performance win. Per-object resource cleanup flags make object deallocation a lot faster. The cost of creating and destroying an object is now roughly cut in half by AArch64. Tagged pointers also make for a nice performance win as well as reducing memory usage.
These are just some of the performance increases that have made huge differences in the A7. But hey think what you want. The proof is in the testing and the A7 is clearly the fastest mobile processor on the market.
Right....That is why I keep referring to large data array software that would benefit from those increase in registers.
How is everyone doing with Touch ID? Mine is quite flaky, working about 20% of the time.
Mine’s not flaky at all. It always unlocks in milliseconds, whether from powered off or the lock screen. it’s barely delayed enough to notice there’s a ‘process’ going on other than powering up the home screen…
I redid my finger scans a couple of times, after paying more attention to what parts of my fingertips are contacting the button when I reach for it without thinking about it. The first time I scanned I treated the process more like “getting my fingerprints taken”. The second time, less so, but I noticed I was still not completely matching the way I naturally touched the button (depending on the finger).
The third time, I scanned all my fingers more accurately using the positions I use when I ‘mindlessly’ reach for the phone. Now, it fires up instantly every time. I no longer frequently get the “Try Again” wiggling message. Maybe once in a hundred or so unlocks?
I scanned four fingers. My left and right thumbs, and L/R index fingers. The fifth I reserved in case I need a second scan of the one I use most (or a stiff drink :P), but so far, all is well…
I would suggest you rescan, making sure you focus on the fingertip areas that naturally tap the button when you unlock it...
To requote what has been quoted for months now since someone in this thread can't be bothered to do any research before posting...
"Apple isn’t very focused on delivering a larger memory address space today however. As A64 is a brand new ISA, there are other benefits that come along with the move. Similar to the x86-64 transition, the move to A64 comes with an increase in the number of general purpose registers. ARMv7 had 15 general purpose registers (and 1 register for the program counter), while ARMv8/A64 now has 31 that are each 64-bits wide. All 31 registers are accessible at all times. Increasing the number of architectural registers decreases register pressure and can directly impact performance. The doubling of the register space with x86-64 was responsible for up to a 10% increase in performance.
The original ARM architecture made all instructions conditional, which had a huge impact on the instruction space. The number of conditional instructions is far more limited in ARMv8/A64.
The move to ARMv8 also doubles the number of FP/NEON registers (from 16 to 32) as well as widens all of them registers to 128-bits (up from 64-bits). Support for 128-bit registers can go a long way in improving SIMD performance. Whereas simply doubling register count can provide moderate increases in performance, doubling the size of each register can be far more significant given the right workload. There are also new advanced SIMD instructions that are a part of ARMv8. Double precision SIMD FP math is now supported among other things.
ARMv8 also adds some new cryptographic instructions for hardware acceleration of AES and SHA1/SHA256 algorithms. These hardware AES/SHA instructions have the potential for huge increases in performance, just like we saw with the introduction of AES-NI on Intel CPUs a few years back. Both the new advanced SIMD instructions and AES/SHA instructions are really designed to enable a new wave of iOS apps."
"It's also important to point out the things that "64-bit" does not refer to, as there's a lot of confusion in this area as well. In particular, "64-bit" does not include:
Physical RAM address size. The number of bits used to actually talk to RAM (and therefore the amount of RAM the hardware can support) is decoupled from the question of CPU bitness. ARM CPUs have ranged from 26 bits to 40 bits, and this can be changed independently from the rest.
Data bus size. The amount of data fetched from RAM or cache is likewise decoupled. Individual CPU instructions may request a certain amount of data, but the amount of data actually fetched can be independent, either by splitting the fetch into smaller parts, or fetching more than is necessary. The iPhone 5 already fetches data from memory in 64-bit chunks, and chunk sizes of up to 192 bits exist in the PC world.
Anything related to floating-point. FPU register size and internal design is independent, and ARM CPUs have had 64-bit FPU registers since well before ARM64.
[…]
Adding it all together, it's a pretty big win. My casual benchmarking indicates that basic object creation and destruction takes about 380ns on a 5S running in 32-bit mode, while it's only about 200ns when running in 64-bit mode. If any instance of the class has ever had a weak reference and an associated object set, the 32-bit time rises to about 480ns, while the 64-bit time remains around 200ns for any instances that were not themselves the target.
In short, the improvements to Apple's runtime make it so that object allocation in 64-bit mode costs only 40-50% of what it does in 32-bit mode. If your app creates and destroys a lot of objects, that's a big deal.
[…]
Apple took advantage of the transition to make some changes of their own. The biggest change is an inline retain count, which eliminates the need to perform a costly hash table lookup for retain and release operations in the common case. Since those operations are so common in most Objective-C code, this is a big win. Per-object resource cleanup flags make object deallocation quite a bit faster in certain cases. All in all, the cost of creating and destroying an object is roughly cut in half. Tagged pointers also make for a nice performance win as well as reduced memory use.
ARM64 is a welcome addition to Apple's hardware. We all knew it would happen eventually, but few expected it this soon. It's here now, and it's great."
Note that AnandTech shows an improvement in AES by 825% (must access link to see results) simply by running as 64-bit. How exactly not a benefit? As I've stated before I think it's worth considering that Touch ID wouldn't be possible without A64's improved crypto and phenomenal AES and SHA speed performance.
So in other words large data array software is what gets the most benefit out of it, which is what I have been saying the entire time. I have been saying the entire time that software such as encryption(hey look AES), encoding, video editing software, etc. would see an actual benefit.
Sadly such software is not the primary software the every day user uses on an iphone 5s or ipad for the majority of the time they use the device. Things like an Internet browser which is the most widely and most commonly used software don't really benefit from a 64 bit transition.
Unless you can show that the iphone 5s and ipad air are going to primarily running or being used for large data array software the majority of the time the user is interacting with the device the performance increase is negligible.
So in other words large data array software is what gets the most benefit out of it, which is what I have been saying the entire time. I have been saying the entire time that software such as encryption(hey look AES), encoding, video editing software, etc. would see an actual benefit.
Sadly such software is not the primary software the every day user uses on an iphone 5s or ipad for the majority of the time they use the device. Things like an Internet browser which is the most widely and most commonly used software don't really benefit from a 64 bit transition.
Unless you can show that the iphone 5s and ipad air are going to primarily running or being used for large data array software the majority of the time the user is interacting with the device the performance increase is negligible.
You wrote…
At the current moment it is because there is no software or hardware now or in the immediate future that will take advantage of the benefits 64 bit brings on a mobile device, ie have more than four GB of system RAM., the iphone 5s only has one GB.
They are only doing it because the average consumer just looks at the number and will think it is superior but when you look at the specs of the phones none of them come close to having enough system RAM for 64 bit to make any difference.
Again, your more recent decision to backpedal on your previous ignorant statement by including "large data sets" to your "only if you have more then 4GB RAM" statement has been proven false as noted by the many posters here as well as links to informed articles you have either failed to read or comprehend.
At the current moment it is because there is no software or hardware now or in the immediate future that will take advantage of the benefits 64 bit brings on a mobile device, ie have more than four GB of system RAM., the iphone 5s only has one GB.
They are only doing it because the average consumer just looks at the number and will think it is superior but when you look at the specs of the phones none of them come close to having enough system RAM for 64 bit to make any difference.
Right. Show me the large data array software that the average user of an iphone 5s device uses for a good portion of their time when interacting with the devices. Just show me that software. The truth of the matter is that every day user of these devices are only really going to notice a difference when the device has more than 4 GB of system RAM.
Right. Show me the large data array software that the average user of an iphone 5s device uses for a good portion of their time when interacting with the devices. Just show me that software. The truth of the matter is that every day user of these devices are only really going to notice a difference when the device has more than 4 GB of system RAM.
1) You didn't include any comments about large data arrays in the comment from you I quoted. You were very specific in your ignorance that RAM was the ONLY reason to go with 64-bit.
2) You've continually ignored the innumerable benefits to A64. Bottom line, you're wrong, you've been proven, and your hubris won't allow you do the right thing by admitting your wrong which unfortunately means you're just going to double down on your ignorance which clearly isn't working for you as noted by your comments here.
I said that your comment that 64-bit is useless without 4+ gigabytes of RAM was incorrect.
Which didn’t happen.
Thus proving wrong your statement that 64-bit is useless without 4+ gigabytes of RAM.
This is what you quoted:
"64 bit address buses only real benefit is that it can address more than 4 GB of system ram"
You stated that statement was incorrect. That is not incorrect.
Actually it didn't prove my statement wrong because those performance increases are primarily from higher core clock speeds, faster LPDDR3 memory and quad-core PowerVR graphics chip — all independent improvements that the A7 makes.
Quote:
Originally Posted by SolipsismX
1) You didn't include any comments about large data arrays in the comment from you I quoted. You were very specific in your ignorance that RAM was the ONLY reason to go with 64-bit.
2) You've continually ignored the innumerable benefits to A64. Bottom line, you're wrong, you've been proven, and your hubris won't allow you do the right thing by admitting your wrong which unfortunately means you're just going to double down on your ignorance which clearly isn't working for you as noted by your comments here.
1. From an end user perspective that doesn't use large data array software the majority of the time they interact with the device, which would be more than 90% of the user base, the only real practical benefit from 64 bit would be the 4 GB+ system ram. That is not an incorrect statement and you know it.
2. I'm not ignoring it at all, what I'm saying is that the 64 bit doesn't have the performance impact that you think it does on the software that the average user runs. You really honestly think that the Facebook, Twitter, Safari, Walgreen, Amazon apps are going to see a noticeable improvement in their performance from solely going from 32 bit to 64 bit? You really think that?
From an end user perspective that doesn't use large data array software the majority of the time they interact with the device, which would be more than 90% of the user base, the only real practical benefit from 64 bit would be the 4 GB+ system ram.
For the last time…
Apple took advantage of the transition to make some changes of their own. The biggest change is an inline retain count, which eliminates the need to perform a costly hash table lookup for retain and release operations in the common case. Since those operations are so common in most Objective-C code, this is a big win. Per-object resource cleanup flags make object deallocation quite a bit faster in certain cases. All in all, the cost of creating and destroying an object is roughly cut in half. Tagged pointers also make for a nice performance win as well as reduced memory use.
Apple took advantage of the transition to make some changes of their own. The biggest change is an inline retain count, which eliminates the need to perform a costly hash table lookup for retain and release operations in the common case. Since those operations are so common in most Objective-C code, this is a big win. Per-object resource cleanup flags make object deallocation quite a bit faster in certain cases. All in all, the cost of creating and destroying an object is roughly cut in half. Tagged pointers also make for a nice performance win as well as reduced memory use.
You really honestly believe that Facebook and Twitter apps are going to run that much faster because of that. I'm not doubting that above in bold, what I'm asking is what is the impact in terms of performance increase for the end user on the most commonly used apps such as Facebook, Twitter, Safari and the answer is negligible and you know it.
[quote name="Richard Getz" url="/t/161372/rumor-lg-hopes-to-catch-up-to-apple-with-fingerprint-sensor-in-next-gen-android-phone#post_2450293"]How is everyone doing with Touch ID? Mine is quite flaky, working about 20% of the time. [/quote Mine works 100^%. Rock solid.
You really honestly believe that Facebook and Twitter apps are going to run that much faster because of that. I'm not doubting that above in bold, what I'm asking is what is the impact in terms of performance increase for the end user on the most commonly used apps such as Facebook, Twitter, Safari and the answer is negligible and you know it.
I own one iPad with an A5X and one with an A7 and the difference is very noticeable in how fast things run. With mobile devices we are not yet at the same point we are with desktops, where faster CPU makes no difference, the CPUs are still slow enough that a doubling in performance is noticeable to human perception.
Also those apps you mentioned are not the most popular (at least in terms of sales), looking at the top 10 apps on the app store, none of those are in there, and 7 of the 10 are games, which surely will benefit a lot.
"64 bit address buses only real benefit is that it can address more than 4 GB of system ram"
You stated that statement was incorrect. That is not incorrect.
So, if it’s not incorrect, explain why an app, unchanged except for its compilation, runs slower in 32-bit mode than in 64-bit mode when actually tested, despite every article downplaying the benefits of 64-bit saying that such programs will run slower because of the extra address space.
You really honestly believe that Facebook and Twitter apps are going to run that much faster because of that. I'm not doubting that above in bold, what I'm asking is what is the impact in terms of performance increase for the end user on the most commonly used apps such as Facebook, Twitter, Safari and the answer is negligible and you know it.
We're discussing the performance and power benefits of the new ISA (which you said wasn't a benefit) your argument is that you won't notice FB and Twitter apps running faster? You mean the user won't see what they type into the text field show up any faster than it does now so it makes the new ISA pointless even though it allows for the CPU to get back to idle and RAM to be released faster? You're right about that but the end result is that the system BENEFITS from 64-bit because the system is more efficient, which is something you said wasn't a benefit in your claim that you need more than 4GB of RAM before 64-bit makes any sense. So yes, apps will run faster especially when it comes to retain and release, but this is all irrelevant to your original point.
Mine’s not flaky at all. It always unlocks in milliseconds, whether from powered off or the lock screen. it’s barely delayed enough to notice there’s a ‘process’ going on other than powering up the home screen…
I redid my finger scans a couple of times, after paying more attention to what parts of my fingertips are contacting the button when I reach for it without thinking about it. The first time I scanned I treated the process more like “getting my fingerprints taken”. The second time, less so, but I noticed I was still not completely matching the way I naturally touched the button (depending on the finger).
The third time, I scanned all my fingers more accurately using the positions I use when I ‘mindlessly’ reach for the phone. Now, it fires up instantly every time. I no longer frequently get the “Try Again” wiggling message. Maybe once in a hundred or so unlocks?
I scanned four fingers. My left and right thumbs, and L/R index fingers. The fifth I reserved in case I need a second scan of the one I use most (or a stiff drink :P), but so far, all is well…
I would suggest you rescan, making sure you focus on the fingertip areas that naturally tap the button when you unlock it...
Yes, sorry, I should have stated in my original post. I rescanned 5 times.
I had someone add their finger and it has read it twice. Testing to see if it is an issue with my prints or the Touch ID.
Yes, sorry, I should have stated in my original post. I rescanned 5 times.
I had someone add their finger and it has read it twice. Testing to see if it is an issue with my prints or the Touch ID.
I had some difficulty. First, I entered the same thumb in my phone twice. I also changed my reading thumb posture. I found that scans are much more reliable if I'm touching only just hard enough to maximize readable print area, but not actually push the button in at all. Maybe this is how it was intended and I didn't pick up on it at first. Pressing the home button in seems to reduce the readable print area, because it's a more deeply recessed pocket then.
I had some difficulty. First, I entered the same thumb in my phone twice. I also changed my reading thumb posture. I found that scans are much more reliable if I'm touching only just hard enough to maximize readable print area, but not actually push the button in at all. Maybe this is how it was intended and I didn't pick up on it at first. Pressing the home button in seems to reduce the readable print area, because it's a more deeply recessed pocket then.
Comments
That I know, I didn't know that "The number of conditional instructions is far more limited in ARMv8/A64."
No, I made no comment as to that. Try again without putting words in others’ mouths.
Yes you have, you said my comment about the address bus was incorrect and then when I proved you wrong you asked "well why does the 64 bit compiled apps show an increase of up to 25%?"
No, no you didn't. You discredited everything that comes with AArch64 and made sweeping ignorant generalizations and even made foolish comments about RAM capacity and CPU bitness.
PS: I checked your posts. You didn't use ISA, AArch64, or the colloquial ARM64 once in your comments.
Huh? Why would I need to use those phrases, words when I can just say 64 bit or A7 when talking about the iphone 5s or ipad air? What else could I possibly be talking about? Is it really that difficult for you to realize that when talking about the A7 you are also talking about ARM64?
None of it was foolish.
Did you know you're incorrectly equating the number of bits with the address bus with number of bits used in other parts of the system.
Right, that is why I repeatedly pointed out that large data array software can take advantage of the 64 bit regardless of the address bus.
Quote:
yes he has. He overlooks that AArch64 doubled the number of registers over 32bit ARM. 32-bit ARM provides 16 integer registers, of which one is a dedicated program counter, two more are give over to a stack pointer and link register, and the other 13 are available for general use. With AArch 64 there are 32 integer registers, with a dedicated zero register, dedicated link register and dedicated frame pointer register. One further register is dedicated to the platform leaving 28 general purpose registers.
AArch 64 also increases the number of floating point registers as well. AArch 32 has 32 32 bit floating point registers. Which can overlap into various sized of floating points as needed. AArch 64 simplifies this and has 32 128 bit floating point registers that can be used for smaller amounts of data, but are dedicated and do not overlap which is a big performance win. With AArch 64 Physical RAM address size is decouple from CPU fitness.Data Bus size the amount of data fetched from RAM is likewise decoupled. A CPU instruction may request a certain size of data but the amount can be independentlycontrolled by either fetching in smaller amounts or fetching more than is necessary.Also a revised and streamlined the instruction set for a big performance gain. Also apple took advantage of AArch64 in a big way with an inline retain count, which eliminates the need to perform costly hash table lookup for retain and release operations in the common case. Those operations are very common in most Objective-C code and is a big performance win. Per-object resource cleanup flags make object deallocation a lot faster. The cost of creating and destroying an object is now roughly cut in half by AArch64. Tagged pointers also make for a nice performance win as well as reducing memory usage.
These are just some of the performance increases that have made huge differences in the A7. But hey think what you want. The proof is in the testing and the A7 is clearly the fastest mobile processor on the market.
Right....That is why I keep referring to large data array software that would benefit from those increase in registers.
This limitation is a good thing. It's basically tightening up the instruction set to make it more efficient.
Mine’s not flaky at all. It always unlocks in milliseconds, whether from powered off or the lock screen. it’s barely delayed enough to notice there’s a ‘process’ going on other than powering up the home screen…
I redid my finger scans a couple of times, after paying more attention to what parts of my fingertips are contacting the button when I reach for it without thinking about it. The first time I scanned I treated the process more like “getting my fingerprints taken”. The second time, less so, but I noticed I was still not completely matching the way I naturally touched the button (depending on the finger).
The third time, I scanned all my fingers more accurately using the positions I use when I ‘mindlessly’ reach for the phone. Now, it fires up instantly every time. I no longer frequently get the “Try Again” wiggling message. Maybe once in a hundred or so unlocks?
I scanned four fingers. My left and right thumbs, and L/R index fingers. The fifth I reserved in case I need a second scan of the one I use most (or a stiff drink :P), but so far, all is well…
I would suggest you rescan, making sure you focus on the fingertip areas that naturally tap the button when you unlock it...
To requote what has been quoted for months now since someone in this thread can't be bothered to do any research before posting...
The original ARM architecture made all instructions conditional, which had a huge impact on the instruction space. The number of conditional instructions is far more limited in ARMv8/A64.
The move to ARMv8 also doubles the number of FP/NEON registers (from 16 to 32) as well as widens all of them registers to 128-bits (up from 64-bits). Support for 128-bit registers can go a long way in improving SIMD performance. Whereas simply doubling register count can provide moderate increases in performance, doubling the size of each register can be far more significant given the right workload. There are also new advanced SIMD instructions that are a part of ARMv8. Double precision SIMD FP math is now supported among other things.
ARMv8 also adds some new cryptographic instructions for hardware acceleration of AES and SHA1/SHA256 algorithms. These hardware AES/SHA instructions have the potential for huge increases in performance, just like we saw with the introduction of AES-NI on Intel CPUs a few years back. Both the new advanced SIMD instructions and AES/SHA instructions are really designed to enable a new wave of iOS apps."
and…
Physical RAM address size. The number of bits used to actually talk to RAM (and therefore the amount of RAM the hardware can support) is decoupled from the question of CPU bitness. ARM CPUs have ranged from 26 bits to 40 bits, and this can be changed independently from the rest.
Data bus size. The amount of data fetched from RAM or cache is likewise decoupled. Individual CPU instructions may request a certain amount of data, but the amount of data actually fetched can be independent, either by splitting the fetch into smaller parts, or fetching more than is necessary. The iPhone 5 already fetches data from memory in 64-bit chunks, and chunk sizes of up to 192 bits exist in the PC world.
Anything related to floating-point. FPU register size and internal design is independent, and ARM CPUs have had 64-bit FPU registers since well before ARM64.
[…]
Adding it all together, it's a pretty big win. My casual benchmarking indicates that basic object creation and destruction takes about 380ns on a 5S running in 32-bit mode, while it's only about 200ns when running in 64-bit mode. If any instance of the class has ever had a weak reference and an associated object set, the 32-bit time rises to about 480ns, while the 64-bit time remains around 200ns for any instances that were not themselves the target.
In short, the improvements to Apple's runtime make it so that object allocation in 64-bit mode costs only 40-50% of what it does in 32-bit mode. If your app creates and destroys a lot of objects, that's a big deal.
[…]
Apple took advantage of the transition to make some changes of their own. The biggest change is an inline retain count, which eliminates the need to perform a costly hash table lookup for retain and release operations in the common case. Since those operations are so common in most Objective-C code, this is a big win. Per-object resource cleanup flags make object deallocation quite a bit faster in certain cases. All in all, the cost of creating and destroying an object is roughly cut in half. Tagged pointers also make for a nice performance win as well as reduced memory use.
ARM64 is a welcome addition to Apple's hardware. We all knew it would happen eventually, but few expected it this soon. It's here now, and it's great."
Note that AnandTech shows an improvement in AES by 825% (must access link to see results) simply by running as 64-bit. How exactly not a benefit? As I've stated before I think it's worth considering that Touch ID wouldn't be possible without A64's improved crypto and phenomenal AES and SHA speed performance.
So in other words large data array software is what gets the most benefit out of it, which is what I have been saying the entire time. I have been saying the entire time that software such as encryption(hey look AES), encoding, video editing software, etc. would see an actual benefit.
Sadly such software is not the primary software the every day user uses on an iphone 5s or ipad for the majority of the time they use the device. Things like an Internet browser which is the most widely and most commonly used software don't really benefit from a 64 bit transition.
Unless you can show that the iphone 5s and ipad air are going to primarily running or being used for large data array software the majority of the time the user is interacting with the device the performance increase is negligible.
You wrote…
At the current moment it is because there is no software or hardware now or in the immediate future that will take advantage of the benefits 64 bit brings on a mobile device, ie have more than four GB of system RAM., the iphone 5s only has one GB.
They are only doing it because the average consumer just looks at the number and will think it is superior but when you look at the specs of the phones none of them come close to having enough system RAM for 64 bit to make any difference.
Again, your more recent decision to backpedal on your previous ignorant statement by including "large data sets" to your "only if you have more then 4GB RAM" statement has been proven false as noted by the many posters here as well as links to informed articles you have either failed to read or comprehend.
You wrote…
At the current moment it is because there is no software or hardware now or in the immediate future that will take advantage of the benefits 64 bit brings on a mobile device, ie have more than four GB of system RAM., the iphone 5s only has one GB.
They are only doing it because the average consumer just looks at the number and will think it is superior but when you look at the specs of the phones none of them come close to having enough system RAM for 64 bit to make any difference.
Right. Show me the large data array software that the average user of an iphone 5s device uses for a good portion of their time when interacting with the devices. Just show me that software. The truth of the matter is that every day user of these devices are only really going to notice a difference when the device has more than 4 GB of system RAM.
I said that your comment that 64-bit is useless without 4+ gigabytes of RAM was incorrect.
Which didn’t happen.
Thus proving wrong your statement that 64-bit is useless without 4+ gigabytes of RAM.
1) You didn't include any comments about large data arrays in the comment from you I quoted. You were very specific in your ignorance that RAM was the ONLY reason to go with 64-bit.
2) You've continually ignored the innumerable benefits to A64. Bottom line, you're wrong, you've been proven, and your hubris won't allow you do the right thing by admitting your wrong which unfortunately means you're just going to double down on your ignorance which clearly isn't working for you as noted by your comments here.
I said that your comment that 64-bit is useless without 4+ gigabytes of RAM was incorrect.
Which didn’t happen.
Thus proving wrong your statement that 64-bit is useless without 4+ gigabytes of RAM.
This is what you quoted:
"64 bit address buses only real benefit is that it can address more than 4 GB of system ram"
You stated that statement was incorrect. That is not incorrect.
Actually it didn't prove my statement wrong because those performance increases are primarily from higher core clock speeds, faster LPDDR3 memory and quad-core PowerVR graphics chip — all independent improvements that the A7 makes.
1) You didn't include any comments about large data arrays in the comment from you I quoted. You were very specific in your ignorance that RAM was the ONLY reason to go with 64-bit.
2) You've continually ignored the innumerable benefits to A64. Bottom line, you're wrong, you've been proven, and your hubris won't allow you do the right thing by admitting your wrong which unfortunately means you're just going to double down on your ignorance which clearly isn't working for you as noted by your comments here.
1. From an end user perspective that doesn't use large data array software the majority of the time they interact with the device, which would be more than 90% of the user base, the only real practical benefit from 64 bit would be the 4 GB+ system ram. That is not an incorrect statement and you know it.
2. I'm not ignoring it at all, what I'm saying is that the 64 bit doesn't have the performance impact that you think it does on the software that the average user runs. You really honestly think that the Facebook, Twitter, Safari, Walgreen, Amazon apps are going to see a noticeable improvement in their performance from solely going from 32 bit to 64 bit? You really think that?
For the last time…
Apple took advantage of the transition to make some changes of their own. The biggest change is an inline retain count, which eliminates the need to perform a costly hash table lookup for retain and release operations in the common case. Since those operations are so common in most Objective-C code, this is a big win. Per-object resource cleanup flags make object deallocation quite a bit faster in certain cases. All in all, the cost of creating and destroying an object is roughly cut in half. Tagged pointers also make for a nice performance win as well as reduced memory use.
I was dabbling on that thought after I shut down my Mac. "Thank Steve for iPads"
Thank you sir for responding. Good luck on educating the uneducated, though I presume this was your last post on that matter.
For the last time…
Apple took advantage of the transition to make some changes of their own. The biggest change is an inline retain count, which eliminates the need to perform a costly hash table lookup for retain and release operations in the common case. Since those operations are so common in most Objective-C code, this is a big win. Per-object resource cleanup flags make object deallocation quite a bit faster in certain cases. All in all, the cost of creating and destroying an object is roughly cut in half. Tagged pointers also make for a nice performance win as well as reduced memory use.
You really honestly believe that Facebook and Twitter apps are going to run that much faster because of that. I'm not doubting that above in bold, what I'm asking is what is the impact in terms of performance increase for the end user on the most commonly used apps such as Facebook, Twitter, Safari and the answer is negligible and you know it.
[/quote
Mine works 100^%. Rock solid.
You really honestly believe that Facebook and Twitter apps are going to run that much faster because of that. I'm not doubting that above in bold, what I'm asking is what is the impact in terms of performance increase for the end user on the most commonly used apps such as Facebook, Twitter, Safari and the answer is negligible and you know it.
I own one iPad with an A5X and one with an A7 and the difference is very noticeable in how fast things run. With mobile devices we are not yet at the same point we are with desktops, where faster CPU makes no difference, the CPUs are still slow enough that a doubling in performance is noticeable to human perception.
Also those apps you mentioned are not the most popular (at least in terms of sales), looking at the top 10 apps on the app store, none of those are in there, and 7 of the 10 are games, which surely will benefit a lot.
"64 bit address buses only real benefit is that it can address more than 4 GB of system ram"
You stated that statement was incorrect. That is not incorrect.
So, if it’s not incorrect, explain why an app, unchanged except for its compilation, runs slower in 32-bit mode than in 64-bit mode when actually tested, despite every article downplaying the benefits of 64-bit saying that such programs will run slower because of the extra address space.
We're discussing the performance and power benefits of the new ISA (which you said wasn't a benefit) your argument is that you won't notice FB and Twitter apps running faster? You mean the user won't see what they type into the text field show up any faster than it does now so it makes the new ISA pointless even though it allows for the CPU to get back to idle and RAM to be released faster? You're right about that but the end result is that the system BENEFITS from 64-bit because the system is more efficient, which is something you said wasn't a benefit in your claim that you need more than 4GB of RAM before 64-bit makes any sense. So yes, apps will run faster especially when it comes to retain and release, but this is all irrelevant to your original point.
Mine’s not flaky at all. It always unlocks in milliseconds, whether from powered off or the lock screen. it’s barely delayed enough to notice there’s a ‘process’ going on other than powering up the home screen…
I redid my finger scans a couple of times, after paying more attention to what parts of my fingertips are contacting the button when I reach for it without thinking about it. The first time I scanned I treated the process more like “getting my fingerprints taken”. The second time, less so, but I noticed I was still not completely matching the way I naturally touched the button (depending on the finger).
The third time, I scanned all my fingers more accurately using the positions I use when I ‘mindlessly’ reach for the phone. Now, it fires up instantly every time. I no longer frequently get the “Try Again” wiggling message. Maybe once in a hundred or so unlocks?
I scanned four fingers. My left and right thumbs, and L/R index fingers. The fifth I reserved in case I need a second scan of the one I use most (or a stiff drink :P), but so far, all is well…
I would suggest you rescan, making sure you focus on the fingertip areas that naturally tap the button when you unlock it...
Yes, sorry, I should have stated in my original post. I rescanned 5 times.
I had someone add their finger and it has read it twice. Testing to see if it is an issue with my prints or the Touch ID.
I had some difficulty. First, I entered the same thumb in my phone twice. I also changed my reading thumb posture. I found that scans are much more reliable if I'm touching only just hard enough to maximize readable print area, but not actually push the button in at all. Maybe this is how it was intended and I didn't pick up on it at first. Pressing the home button in seems to reduce the readable print area, because it's a more deeply recessed pocket then.
Oh no! You pushed the button? You don't have to!