Samsung are an embarrassing company. I'm surprised more people in the western world buy into their garbage.
I think they have a portion of their brain that might not be wired properly. I talked to one person and told them all of the flaws in the platform, and they told me that they didn't care. Just OS update policies and practices alone is enough not to buy an OEM Android product.
Yeah I was thinking...Android I don't believe even supports 64-bit processing so whats the use? And, I don't believe there to be any kind of developer kit to make things 64-bit on Android.
That's part of the issue when hardware and software come from two parties.
Neither one generally wants to be the one to spend the r&d on adding something that isn't supported by the other side. Creating a vicious cycle.
Samsung is so hung up on not being outdone by Apple because they want their stuff to be what beats the fruit that when Apple said they are doing 64 bit, Samsung felt they had to jump in publicly. So now that they have said this, Google will be pushed into work or risk that Samsung will make the changes for them. Which might not be a bad thing from a user point of view.
A 64-bit processor isn't a big deal unless the device has > 4GB of RAM. The fact that either company is using it for marketing purposes at this point is ridiculous. Will it make Apple's life easier to have iOS and OSX both as 64-bit? Sure. But just because 64 > 32 doesn't mean this was a revolutionary move on Apple's part. One day, phones may get more RAM and this move will pay off for consumers. Not right now. Even then, it's highly unlikely that a mobile OS in the next 10 years will allow a single application to address anywhere near 4GB of memory.
Keep in mind that since most Android apps are built entirely in Java, which runs on top of the Java Virtual Machine, all of these Android apps will run in 64-bit mode once the JVM is ported to run in 64-bit mode. They don't need to be rebuilt/resubmitted to the Play store. With Apple, most apps are compiled to native binaries (no VM layer). While this has performance benefits, it's going to be a pain in the ass for developers to migrate from 32 to 64-bit--significantly harder than it will be for Android developers. This is a step that Apple needed to take first. Remember their growing pains around the switch of OSX to 64-bit? Universal binaries vs. 32-bit binaries? Same problem they're trying to solve here.
There is a lot more to go with having 64 bit wide register than only addressing more than 4GB of ram.
Beside Android is currently years away from being a 64bit OS, the Linux kernel and userland needs to be ported first and than the whole Dalvik VM will all its library needs to be ported.
Can I ask you what pains you got from switch OSX to 64bit? The transition cannot have been smoother for Apple. All OSX apps transparently run on any 32 or 64 bit Intel Macintoshs since OSX executable can bundle multiple arch binary. Same thing will apply for iOS apps, developer will only need to flip a switch in there Xcode project to generate their 32/64 bits universal apps. Android is very far from having a similar universal apps solution.
My dream machine would have the functionality of OSX on an iPad pro with a wacom digitizer. That way I can run adobe illustrator and photoshop while sitting on the couch. Make it happen
From a technical standpoint, 64 bits is not needed for a mobile device. This change is all about bragging rights.
Hopefully consumers will wise up to the lack of need for 64-bits and save themselves some money.
I agree a bit. It may be overkill on a phone. But with a tablet perhaps not.
As for the money, if it comes with no overhead to the consumer versus the historical pricing, such as Apple has done, and might improve stability etc. Well why not.
A 64-bit processor isn't a big deal unless the device has > 4GB of RAM. The fact that either company is using it for marketing purposes at this point is ridiculous. Will it make Apple's life easier to have iOS and OSX both as 64-bit? Sure. But just because 64 > 32 doesn't mean this was a revolutionary move on Apple's part. One day, phones may get more RAM and this move will pay off for consumers. Not right now. Even then, it's highly unlikely that a mobile OS in the next 10 years will allow a single application to address anywhere near 4GB of memory.
Keep in mind that since most Android apps are built entirely in Java, which runs on top of the Java Virtual Machine, all of these Android apps will run in 64-bit mode once the JVM is ported to run in 64-bit mode. They don't need to be rebuilt/resubmitted to the Play store. With Apple, most apps are compiled to native binaries (no VM layer). While this has performance benefits, it's going to be a pain in the ass for developers to migrate from 32 to 64-bit--significantly harder than it will be for Android developers. This is a step that Apple needed to take first. Remember their growing pains around the switch of OSX to 64-bit? Universal binaries vs. 32-bit binaries? Same problem they're trying to solve here.
Yes, that was an awfully difficult transition from a user standpoint.
I remember weeping - WEEPING, when System Preferences occasionally had to close and re-open in 32-bit mode.
To be honest, I wonder if I'll ever get over the psychological scarring it caused.
Here's what the 'raw power' of 64-bit actually means. Instead of a pointer to a location in memory being 32-bits, it's 64-bits. Each bit can be 0 or 1 (2 states).
So instead of 2^32 = 4,294,967,296 bytes = 4,194,304 KB = 4,096 MB = 4 GB being the maximum memory address...
There is no other magical power to this. It will be 2-3 years minimum before a cell phone has > 4GB of RAM in it. With virtual memory management by the OS, it can allocate more than the 4GB/16EB limit to processes by swapping 'pages' of memory out to a larger but slower memory mechanism (disk)--think swap files... and so 4GB (32-bit) or 16EB (64-bit) is the maximum amount of memory any particular process can address.
Regardless of whether you hate Apple, Samsung, Google, Samsung, or RIM.... none of them is going to let your mobile app allocate 4GB of RAM (virtual or otherwise) because it would put too much strain on the rest of the OS and would be too I/O+battery intensive swapping pages in and out from flash memory... So for the time being, unless your an iOS developer who needs to change their code to support 64-bit addresses, this is buzz word marketing at it's best and you've all had too much Kool Aid.
FWIW, if Samsung is ripping off Apple by increasing addressable memory space, then Apple ripped off Windows who ripped off Linux just like Nintendo ripped off Sega who ripped off Nintendo who ripped off Atari.
From a technical standpoint, 64 bits is not needed for a mobile device. This change is all about bragging rights.
Hopefully consumers will wise up to the lack of need for 64-bits and save themselves some money.
I think most of us forget how CPU intensive every day stuff like encryption, image, sound and video processing can be. I'm pretty sure without the A7, Apple couldn't add so many feature to the photo apps or do 120fps 720p video on the iPhone 5S
Keep in mind that since most Android apps are built entirely in Java, which runs on top of the Java Virtual Machine, all of these Android apps will run in 64-bit mode once the JVM is ported to run in 64-bit mode. They don't need to be rebuilt/resubmitted to the Play store. With Apple, most apps are compiled to native binaries (no VM layer). While this has performance benefits, it's going to be a pain in the ass for developers to migrate from 32 to 64-bit--significantly harder than it will be for Android developers. This is a step that Apple needed to take first. Remember their growing pains around the switch of OSX to 64-bit? Universal binaries vs. 32-bit binaries? Same problem they're trying to solve here.
1. You seem to forget the Android NDK. Most games and any application that needs performance use it.
2. Porting JVM to 64-bit does not instantly solve all issues as a lot of developers use low-level APIs that are dependent on the underlying architecture, to show mastery.
3. 64-bit CPUs and Operating Systems support 32-bit applications, so there is no need to migrate all apps.
4. Objective-C is high-level, and most low-level and primitive types (such as those in Core Foundation) are carefully defined. So, most apps will be very easy to migrate to 64-bits. Even Infinity Blade 3* was ported in 2 hours (that's what one of ChAIR's developers said).
* I mention a game since game developers are the ones doing low-level hacks, to improve performance.
Here's what the 'raw power' of 64-bit actually means. Instead of a pointer to a location in memory being 32-bits, it's 64-bits. Each bit can be 0 or 1 (2 states).
So instead of 2^32 = 4,294,967,296 bytes = 4,194,304 KB = 4,096 MB = 4 GB being the maximum memory address...
There is no other magical power to this. It will be 2-3 years minimum before a cell phone has > 4GB of RAM in it. With virtual memory management by the OS, it can allocate more than the 4GB/16EB limit to processes by swapping 'pages' of memory out to a larger but slower memory mechanism (disk)--think swap files... and so 4GB (32-bit) or 16EB (64-bit) is the maximum amount of memory any particular process can address.
Regardless of whether you hate Apple, Samsung, Google, Samsung, or RIM.... none of them is going to let your mobile app allocate 4GB of RAM (virtual or otherwise) because it would put too much strain on the rest of the OS and would be too I/O+battery intensive swapping pages in and out from flash memory... So for the time being, unless your an iOS developer who needs to change their code to support 64-bit addresses, this is buzz word marketing at it's best and you've all had too much Kool Aid.
FWIW, if Samsung is ripping off Apple by increasing addressable memory space, then Apple ripped off Windows who ripped off Linux just like Nintendo ripped off Sega who ripped off Nintendo who ripped off Atari.
You are wrong on the meaning of 64 bit, you explanation is only a consequence of having 64 bit wide register.
Having a 64 bit CPU means it can calculate number 2^64 wide instead of 2^32 per clock tick which can lead to doubling the speed of some operations in theory. All of this already have been discuss 10 years ago when Apple as made the first 64 bit personals computer, the PowerMac G5
I like taking pot shots at Samsung as much as anyone else but let's not fabricate stuff.
The iPhone 5/5C/4S users will all still be running the 32 bit version of iOS7 and apps.
It will take a few years before more than 90% of users will be full 64 bit. Granted, the transition will be much quicker for the iOS user base than it will, for the Android user base but 1 year is definitely not enough time, even for Apple.
iOS7 already is 64-bit.
Any iOS application that does not resort to low-level hacks (usually games, for performance reasons) will be migrated by simply rebuilding the code.
PaulMJohnson, BigMac2 -- The pain around the 32-bit to 64-bit was felt by the developers, not by consumers (unless you were waiting on a developer to update an app you needed). It works like this. You have a product that works perfectly. Then the OS migrates from 32-bit to 64-bit. Then you need to put a significant amount of work into making your code compatible again. That Universal Binary thing was basically just a way to put a 32-bit binary and a 64-bit binary in the same file and let the OS decide. The developers still needed to make their code 64-bit compatible.
I'm not saying the move to 64-bit is a bad thing, but a) it's not a revolutionary Apple idea and b) it's not going to pay any dividends to consumers for a long time in smart phones.
Competition based on tearing apart your competitor's product to try and emulate it is not.
The term 'reverse engineering' came about because tearing about a competitor's product is quite common. Americans might be speaking German if the US hadn't reversed engineered the enigma machines hell they even reverse engineered German gas cans. I'm not saying it's right but it happens a whole lot.
Oh come on guys. Cut Samsung some slack. They're innovative. Now that they announced their plans for a 64-bit phone, they're running around yelling to their "engineers" to find a 64-bit Android OS to copy.. errr... download.
PaulMJohnson, BigMac2 -- The pain around the 32-bit to 64-bit was felt by the developers, not by consumers (unless you were waiting on a developer to update an app you needed). It works like this. You have a product that works perfectly. Then the OS migrates from 32-bit to 64-bit. Then you need to put a significant amount of work into making your code compatible again. That Universal Binary thing was basically just a way to put a 32-bit binary and a 64-bit binary in the same file and let the OS decide. The developers still needed to make their code 64-bit compatible.
I'm not saying the move to 64-bit is a bad thing, but a) it's not a revolutionary Apple idea and b) it's not going to pay any dividends to consumers for a long time in smart phones.
Can you elaborate more on your so-called pain felt by the developers? Because this is not reflecting what developer says about Xcode IDE. It took 2 hours to port on 64bit iOS one of its biggest game. Same thing happens on OSX, almost every current apps are universal and transparently run on 32 and 64 bit arch, it require only flicking a switch in Xcode project for developer to maintain both arch with the same codebase and assets.
Also, Apple now has a 3 year period before all phones offered for sale will all be 64-bit. OS7 is 64-bit on the 5S and I wonder when Android will be 64-bit? Samsung????
Apple makes these changes to set themselves up for something down the road. Nothing is by chance here. That goes for the finger print scanner...presented as a side note almost but where will it be in a year or 2. The operate on vision for the future not a flash today and gone tomorrow.
Comments
Samsung are an embarrassing company. I'm surprised more people in the western world buy into their garbage.
I think they have a portion of their brain that might not be wired properly. I talked to one person and told them all of the flaws in the platform, and they told me that they didn't care. Just OS update policies and practices alone is enough not to buy an OEM Android product.
From a technical standpoint, 64 bits is not needed for a mobile device. This change is all about bragging rights.
Hopefully consumers will wise up to the lack of need for 64-bits and save themselves some money.
Neither one generally wants to be the one to spend the r&d on adding something that isn't supported by the other side. Creating a vicious cycle.
Samsung is so hung up on not being outdone by Apple because they want their stuff to be what beats the fruit that when Apple said they are doing 64 bit, Samsung felt they had to jump in publicly. So now that they have said this, Google will be pushed into work or risk that Samsung will make the changes for them. Which might not be a bad thing from a user point of view.
A 64-bit processor isn't a big deal unless the device has > 4GB of RAM. The fact that either company is using it for marketing purposes at this point is ridiculous. Will it make Apple's life easier to have iOS and OSX both as 64-bit? Sure. But just because 64 > 32 doesn't mean this was a revolutionary move on Apple's part. One day, phones may get more RAM and this move will pay off for consumers. Not right now. Even then, it's highly unlikely that a mobile OS in the next 10 years will allow a single application to address anywhere near 4GB of memory.
Keep in mind that since most Android apps are built entirely in Java, which runs on top of the Java Virtual Machine, all of these Android apps will run in 64-bit mode once the JVM is ported to run in 64-bit mode. They don't need to be rebuilt/resubmitted to the Play store. With Apple, most apps are compiled to native binaries (no VM layer). While this has performance benefits, it's going to be a pain in the ass for developers to migrate from 32 to 64-bit--significantly harder than it will be for Android developers. This is a step that Apple needed to take first. Remember their growing pains around the switch of OSX to 64-bit? Universal binaries vs. 32-bit binaries? Same problem they're trying to solve here.
There is a lot more to go with having 64 bit wide register than only addressing more than 4GB of ram.
Beside Android is currently years away from being a 64bit OS, the Linux kernel and userland needs to be ported first and than the whole Dalvik VM will all its library needs to be ported.
Can I ask you what pains you got from switch OSX to 64bit? The transition cannot have been smoother for Apple. All OSX apps transparently run on any 32 or 64 bit Intel Macintoshs since OSX executable can bundle multiple arch binary. Same thing will apply for iOS apps, developer will only need to flip a switch in there Xcode project to generate their 32/64 bits universal apps. Android is very far from having a similar universal apps solution.
My dream machine would have the functionality of OSX on an iPad pro with a wacom digitizer. That way I can run adobe illustrator and photoshop while sitting on the couch. Make it happen
White, after all they wouldn't want to be copying.
I agree a bit. It may be overkill on a phone. But with a tablet perhaps not.
As for the money, if it comes with no overhead to the consumer versus the historical pricing, such as Apple has done, and might improve stability etc. Well why not.
A 64-bit processor isn't a big deal unless the device has > 4GB of RAM. The fact that either company is using it for marketing purposes at this point is ridiculous. Will it make Apple's life easier to have iOS and OSX both as 64-bit? Sure. But just because 64 > 32 doesn't mean this was a revolutionary move on Apple's part. One day, phones may get more RAM and this move will pay off for consumers. Not right now. Even then, it's highly unlikely that a mobile OS in the next 10 years will allow a single application to address anywhere near 4GB of memory.
Keep in mind that since most Android apps are built entirely in Java, which runs on top of the Java Virtual Machine, all of these Android apps will run in 64-bit mode once the JVM is ported to run in 64-bit mode. They don't need to be rebuilt/resubmitted to the Play store. With Apple, most apps are compiled to native binaries (no VM layer). While this has performance benefits, it's going to be a pain in the ass for developers to migrate from 32 to 64-bit--significantly harder than it will be for Android developers. This is a step that Apple needed to take first. Remember their growing pains around the switch of OSX to 64-bit? Universal binaries vs. 32-bit binaries? Same problem they're trying to solve here.
Yes, that was an awfully difficult transition from a user standpoint.
I remember weeping - WEEPING, when System Preferences occasionally had to close and re-open in 32-bit mode.
To be honest, I wonder if I'll ever get over the psychological scarring it caused.
Here's what the 'raw power' of 64-bit actually means. Instead of a pointer to a location in memory being 32-bits, it's 64-bits. Each bit can be 0 or 1 (2 states).
So instead of 2^32 = 4,294,967,296 bytes = 4,194,304 KB = 4,096 MB = 4 GB being the maximum memory address...
2^64 = 18,446,744,073,709,551,616 bytes = 18,014,398,509,481,984 KB = 17,592,186,044,416 MB = 17,179,869,184 GB = 16,777,216 TB = 16,384 PB = 16 EB (exabytes) is...
There is no other magical power to this. It will be 2-3 years minimum before a cell phone has > 4GB of RAM in it. With virtual memory management by the OS, it can allocate more than the 4GB/16EB limit to processes by swapping 'pages' of memory out to a larger but slower memory mechanism (disk)--think swap files... and so 4GB (32-bit) or 16EB (64-bit) is the maximum amount of memory any particular process can address.
Regardless of whether you hate Apple, Samsung, Google, Samsung, or RIM.... none of them is going to let your mobile app allocate 4GB of RAM (virtual or otherwise) because it would put too much strain on the rest of the OS and would be too I/O+battery intensive swapping pages in and out from flash memory... So for the time being, unless your an iOS developer who needs to change their code to support 64-bit addresses, this is buzz word marketing at it's best and you've all had too much Kool Aid.
FWIW, if Samsung is ripping off Apple by increasing addressable memory space, then Apple ripped off Windows who ripped off Linux just like Nintendo ripped off Sega who ripped off Nintendo who ripped off Atari.
From a technical standpoint, 64 bits is not needed for a mobile device. This change is all about bragging rights.
Hopefully consumers will wise up to the lack of need for 64-bits and save themselves some money.
I think most of us forget how CPU intensive every day stuff like encryption, image, sound and video processing can be. I'm pretty sure without the A7, Apple couldn't add so many feature to the photo apps or do 120fps 720p video on the iPhone 5S
Keep in mind that since most Android apps are built entirely in Java, which runs on top of the Java Virtual Machine, all of these Android apps will run in 64-bit mode once the JVM is ported to run in 64-bit mode. They don't need to be rebuilt/resubmitted to the Play store. With Apple, most apps are compiled to native binaries (no VM layer). While this has performance benefits, it's going to be a pain in the ass for developers to migrate from 32 to 64-bit--significantly harder than it will be for Android developers. This is a step that Apple needed to take first. Remember their growing pains around the switch of OSX to 64-bit? Universal binaries vs. 32-bit binaries? Same problem they're trying to solve here.
1. You seem to forget the Android NDK. Most games and any application that needs performance use it.
2. Porting JVM to 64-bit does not instantly solve all issues as a lot of developers use low-level APIs that are dependent on the underlying architecture, to show mastery.
3. 64-bit CPUs and Operating Systems support 32-bit applications, so there is no need to migrate all apps.
4. Objective-C is high-level, and most low-level and primitive types (such as those in Core Foundation) are carefully defined. So, most apps will be very easy to migrate to 64-bits. Even Infinity Blade 3* was ported in 2 hours (that's what one of ChAIR's developers said).
* I mention a game since game developers are the ones doing low-level hacks, to improve performance.
Here's what the 'raw power' of 64-bit actually means. Instead of a pointer to a location in memory being 32-bits, it's 64-bits. Each bit can be 0 or 1 (2 states).
So instead of 2^32 = 4,294,967,296 bytes = 4,194,304 KB = 4,096 MB = 4 GB being the maximum memory address...
2^64 = 18,446,744,073,709,551,616 bytes = 18,014,398,509,481,984 KB = 17,592,186,044,416 MB = 17,179,869,184 GB = 16,777,216 TB = 16,384 PB = 16 EB (exabytes) is...
There is no other magical power to this. It will be 2-3 years minimum before a cell phone has > 4GB of RAM in it. With virtual memory management by the OS, it can allocate more than the 4GB/16EB limit to processes by swapping 'pages' of memory out to a larger but slower memory mechanism (disk)--think swap files... and so 4GB (32-bit) or 16EB (64-bit) is the maximum amount of memory any particular process can address.
Regardless of whether you hate Apple, Samsung, Google, Samsung, or RIM.... none of them is going to let your mobile app allocate 4GB of RAM (virtual or otherwise) because it would put too much strain on the rest of the OS and would be too I/O+battery intensive swapping pages in and out from flash memory... So for the time being, unless your an iOS developer who needs to change their code to support 64-bit addresses, this is buzz word marketing at it's best and you've all had too much Kool Aid.
FWIW, if Samsung is ripping off Apple by increasing addressable memory space, then Apple ripped off Windows who ripped off Linux just like Nintendo ripped off Sega who ripped off Nintendo who ripped off Atari.
You are wrong on the meaning of 64 bit, you explanation is only a consequence of having 64 bit wide register.
Having a 64 bit CPU means it can calculate number 2^64 wide instead of 2^32 per clock tick which can lead to doubling the speed of some operations in theory. All of this already have been discuss 10 years ago when Apple as made the first 64 bit personals computer, the PowerMac G5
I like taking pot shots at Samsung as much as anyone else but let's not fabricate stuff.
The iPhone 5/5C/4S users will all still be running the 32 bit version of iOS7 and apps.
It will take a few years before more than 90% of users will be full 64 bit. Granted, the transition will be much quicker for the iOS user base than it will, for the Android user base but 1 year is definitely not enough time, even for Apple.
iOS7 already is 64-bit.
Any iOS application that does not resort to low-level hacks (usually games, for performance reasons) will be migrated by simply rebuilding the code.
PaulMJohnson, BigMac2 -- The pain around the 32-bit to 64-bit was felt by the developers, not by consumers (unless you were waiting on a developer to update an app you needed). It works like this. You have a product that works perfectly. Then the OS migrates from 32-bit to 64-bit. Then you need to put a significant amount of work into making your code compatible again. That Universal Binary thing was basically just a way to put a 32-bit binary and a 64-bit binary in the same file and let the OS decide. The developers still needed to make their code 64-bit compatible.
I'm not saying the move to 64-bit is a bad thing, but a) it's not a revolutionary Apple idea and b) it's not going to pay any dividends to consumers for a long time in smart phones.
The term 'reverse engineering' came about because tearing about a competitor's product is quite common. Americans might be speaking German if the US hadn't reversed engineered the enigma machines hell they even reverse engineered German gas cans. I'm not saying it's right but it happens a whole lot.
Copycats!
Did you make the same comment when Apple copied the larger screens on typical Android devices for the iPhone 5?
PaulMJohnson, BigMac2 -- The pain around the 32-bit to 64-bit was felt by the developers, not by consumers (unless you were waiting on a developer to update an app you needed). It works like this. You have a product that works perfectly. Then the OS migrates from 32-bit to 64-bit. Then you need to put a significant amount of work into making your code compatible again. That Universal Binary thing was basically just a way to put a 32-bit binary and a 64-bit binary in the same file and let the OS decide. The developers still needed to make their code 64-bit compatible.
I'm not saying the move to 64-bit is a bad thing, but a) it's not a revolutionary Apple idea and b) it's not going to pay any dividends to consumers for a long time in smart phones.
Can you elaborate more on your so-called pain felt by the developers? Because this is not reflecting what developer says about Xcode IDE. It took 2 hours to port on 64bit iOS one of its biggest game. Same thing happens on OSX, almost every current apps are universal and transparently run on 32 and 64 bit arch, it require only flicking a switch in Xcode project for developer to maintain both arch with the same codebase and assets.
Also, Apple now has a 3 year period before all phones offered for sale will all be 64-bit. OS7 is 64-bit on the 5S and I wonder when Android will be 64-bit? Samsung????
Apple makes these changes to set themselves up for something down the road. Nothing is by chance here. That goes for the finger print scanner...presented as a side note almost but where will it be in a year or 2. The operate on vision for the future not a flash today and gone tomorrow.