Android will have to move to 64-bit sooner or later, because some of the high end devices have RAM creeping uncomfortably close to 4gb. The Moto X, Nexus 7, and pretty much every other flagship phone or tablet all have 2gb RAM. The Galaxy Note 3 has 3gb RAM. A transition to 64 bit would happen primarily for memory reasons, not for some magic performance increase.
I don't argue the fact. I argue the attempts to downplay Apple's move to 64-bit architecture and it's benefits.
Here is something to think about:
The 32-bitWindows Server 2000 Datacenter Edition could address up to 256GB RAM. How did they do it? 48-bit addressing (effectively using 38-bit physical address lane), similar to the way the Intel 80286 (16-bit) processor was capable of addressing up to 16MB RAM (24-bit addressing; 16-bit allows for only 64KB).
The 32-bit/4GB barrier could be crossed by paging the RAM in multiple 4GB pages. That, of course, requires OS support. In such a scenario, the OS could support more than 4GB RAM. Each application will be restricted to 4GB linear address space, but multiple applications could be hosted in different areas utilising all the available memory. Programs that require more RAM, should support paging.
So, 64-bit architecture is NOT a requirement for supporting more than 4GB of RAM. Due to the complications around paging+memory virtualization in the software and system libraries, however, that approach is generally avoided.
I'm interested in reading a good honest article about 64-bit and what this means for Apple vs Windows vs Android, unfortunately this DED guy is really crazy and I can't trust a single word he says. Actually I just couldn't read more than a few paragraphs. He makes me sick.
It's not easy to explain when and how 64-bit are good or bad.
Often 64-bit architectures are presented using concepts valid many years ago, when 16-bit was cutting edge. In those years 16-bit CPUs basically had a 16-bit memory bus, a 16-bit instruction set, 16-bit internal data paths, 16-bit internal registers, 16-bit arithmetic logic units, 16-bit address space.
Modern 32-bit CPUs are quite different. External memory bus could be 64-bit or more, instruction set is much more complex and has SIMD extensions capable of handling vectors of data (not a single 32-bit number), internal data paths are insanely large, internal registers are definitely bigger than 32-bit, there are multiple ALUs of different kinds with SIMD capabilities. And some 32-bit CPUs are capable of handling more than 4GB of RAM through PAE support (basically an artificial extension of the addressing bits).
So, what is a 64-bit CPU ? 64-bit is basically a reference to the addressing space, pointers to memory locations have that size.
Advantage) 64-bit CPUs allows to natively address more than 2^32 = 4GB of RAM. Note that some 32-bit architectures have physical address extensions (PAE) to partially address this 32-bit limitation.
Advantage) Even if only 4GB (or less) are present, the 64-bit CPU still has a 64-bit virtual address space, that allows much more flexibility in memory mapping of large datasets (numerical analysis, movie and image processing, ...)
Disadvantage) Extending internal registers and path to support 64-bit address space has a small cost in term of silicon area and power consumption.
Myth) 64-bit CPUs do not have double processing power with respect to 32-bit one with the very same Arythmetic Logic Unit. Remember that 64-bit are only for the address space, the internal number crunching units are not changed by 32-bit to 64-bit transition.
Myth) While 32-bit means 2^32 = 4 GB support, this is not true for 64-bit. Current 64-bit architectures do not support 2^64 = huge_amount of memory. For example AMD64 architecture supports only 2^48 = 256TB of physical RAM, reserving remaining bits for improvement in the future. I am not sure about ARMv8, but I think 2^39.
Sorry for the wall of text. I hope it can help to clarify some marketing techno-bubbles.
Great write-up as always! But for some the new 64-bit A7, M7 co-processor, improved camera and Touch ID sensor is just a list of meaningless words. And people shouldn't underestimate that with the 5C:
"64-bit mobile ARM processors have been in the pipeline for a long time" is somewhat true, but you're missing the fact that they were targeting server applications. Nobody had any inkling of putting a 64-bit SoC in a phone.
Actually it has been talked about, I'm on record someplace here as saying that iPad needs such a transition as soon as possible. That was widely dismissed. The problem here is that people don't understand system archecture nor where hardware will be 2 years down the road.
That's why the tech media refused to believe it was real, and why exVPs from AMD rushed out to say it was hogwash and made no sense to attempt.
I think many people just don't grasp the value of a move to 64 bit especially with the transition to 14 mm processes so near. The extra space 14nm provides means that developers have to find the best way to leverage that space. The architectural enhancements to Arch64 is one way to gin significant advantage while saving space on die for other architectural advancements. Beyond that large RAM systems are not far away at all, using memory mapped I/O means that the real RAM barrier on 32 bit hardware is someplace in the 2-3GB range. Frankly it is no surprise that we have ex-VP saying such foolishness as AMD wouldn't want such stupidity in their organization when it is trying to recover.
Look at it this way even if it takes two more years to get to 14nm Apple already has the infrastructure in place to leverage the advantages those shrinks will provide. It also means that Apple will target 14nm with an enhanced or updated 64 bit complex rather than their first effort at 64 bit. They will have intrinsic knowledge of where the processor and support electronics need to be improved to best support iOS and its apps. In simple terms 64 bit is huge for Apple and its users and has put them well ahead of the pack.
If you've been paying attention, you'll recall this all happened before when Apple released the iPhone. RIM BB & Microsoft scoffed at the idea of putting a desktop OS on a high end mobile phone. A mixture of contempt and disbelief.
Many RIM engineers where in fact on record expressing disbelief that Apple was able to pull off what they did with iPhone 1. That just highlights the lack of forward thinking or the ability to grasp where silicon process shrinks are taking us. It literally is the same non sense all over again.
Also: does Google have its own x86 port of Android or was that just an effort by Intel to enter the mobile market? Who uses it?
(Crickets)
Who cares? Really people see Android as Apples competition here but I don't think that is actually the whole ball of wax. Apple is really going after established PC architectures here, Windows and the like. I was reluctant to believe in the post PC era but I do believe they are onto something here. IOS, iPad and iPhone are just starting to mature to the point where they are good enough to truly impact the PC world. 64 bit hardware just removes one obstical in that undermining of the PC world.
well, we certainly have dueling"experts" here today. but it all comes down to this:
- either Google ships a finished 64 bit version of Android in 2014 (not yet another pure hype test beta) along with upgraded Google apps for both smartphones and tablets, or it doesn't.
- if yes, either that 64 bit Android actually improves performance and/or supports new features, or it doesn't.
- if it does, either those 64 bit chipset high-end Android smartphones/tablets sell well in direct competition with the iPhone/iPad, or they don't.
- if they do, either developers also produce updated 64 bit apps for them, including tablet versions, or they don't.
- and if they do, either those owners actually buy those upgraded apps, or they don't.
there are a whole lot of "doesn'ts/don'ts" on this list - and like Sam Spade said, "look at the number of them." and then ...
- in any event, either Samsung formally forks its version of Android away from Google and/or launches Tizen, either with 64 bit, or it doesn't.
- either Google sidetracks Android (still at 32 bit?) and applies Chrome OS to its own brand of smartphones as its future priority, or it doesn't.
i wish there was a way to bring this thread back a year from now, where we could nail down which "expert" got it right - and how everything 64 bit actually turned out.
but what we do know for sure now is:
- Apple is shipping 64 bit iPhones today with upgraded Apple apps, with iPads sure to follow next month.
- This already improves performance and supports new features (like the major advances in the camera app).
- They will sell 100+ million 64 bit iPhones/iPads in the next year.
- so developers will rush to produce upgraded/enhanced 64 bit apps for iPhone/iPad, because ...
- iPhone/iPad owners will pay for noticeably enhanced apps.
basically, everything the Android fan people here are saying boils down to "coulda, woulda, shoulda." but the truth is, Apple just cleaned Android's clock, and they know it.
OK, enlighten me as to what is going to be in Android 5.0 then?
Have a break, have a KitKat
Google is currently working on Android 4.4, soon to be released. They've announced 5.0, and are obviously working on it. Whether they've already made it 64-bit, or will make it for the final release, is totally irrelevant.
As I said in an earlier post:
If 64-bit is insignificant, why did Samsung CEO pledged 64-bit support? Why would be Google making Android 64-bit? RAM? Most Personal Computers do just fine with 4GB RAM. Running MacOS X or say latest Fedora Linux (with KDE) requires less than 2GB in general.
Most high-end Android devices compete on specs, and that's why they pack 3GB of RAM. So, that's a barrier reached due to that being possible (and looks nice on a spec sheet), not because of necessity.
There is a lot of confusion about why Apple decided to go to a 64 bit ARMv8 architecture for their A7 processor in the iPhone 5S. There is also a lot of doubt about their claim of double CPU performance. I know that 64 bit is essential for further progress in mobile computing and expect that the double performance claim will prove to be accurate. Here is why.
Let's start with the performance claim. The A7 processor has twice the floating point and general purpose registers. This means it can perform math a lot faster. The problem is that in order to fully utilize these new abilities you need to compile code that takes full advantage of it. That code cannot run on earlier processors so you also need a fat binary to support earlier iOS devices. Until a developer compiles their app with 64 bit support they won't see a big speed increase (perhaps the 30% seen in earlier reports). It is not the 64 bit that is giving the 2x speed, it is the code compiled for the A7's new instruction set.
So why 64 bits? After all the iPhone 5S has just 1GB of RAM which is much less than the 4GB address limit for a 32 bit app. As it turns out the address space is the biggest limitation for a 32 bit app not the RAM size. iOS has a fully featured operating system and can read large files by addressing them as if they were loaded into memory. This trick allow apps to make optimum use of the available RAM (which is less than 512MB) by using the operating system's ability to keep around just the pages that are in use and load others as they are needed. The problem is that it may not be possible to get large contiguous blocks of address space once it becomes fragmented. In addition the operating system itself is using a lot of the virtual address space for the various services it is providing to the app such as maps or the web browser.
64 bit solves all this by providing what may as well be an unlimited amount of address space. My own 3D mapping apps can now address their large map files as a single block of address space. The USA takes up about 6 GB at the best resolution. With 64 bit addressing, it would be possible to drive coast to coast without having to load any additional files because they would all be loaded into the virtual address space and then paged efficiently into the available RAM.
In the future you can expect to see amazing increases in flash memory performance. Apple will be able to blur the distinction between physical RAM and virtual address space. That means that apps will be able to allocate as much memory as there is available flash storage. This will make video editing, 3D rendering and other data intensive tasks traditionally performed on desktop computers possible to do on a tablet or even an iPhone.
This is my point: Don't treat the A7 processor and 64 bits lightly. Apple's processor group is firing on all cylinders and continues to amaze with 2x speed increases year after year at a time when Intel can barely squeeze out 5 or 10% speed increases on desktop CPUs. Samsung and the other smart phone makers must now scramble to catch up with the A7's advanced 64 bit architecture and blazing performance. The A7 with its dual cores will be out performing other processors with 8 cores and that performance will be visible in all apps not just the few that can take full advantage of many threads.
One of the underrated disasters of using 32-bit integers is that they are just big enough to work as counters for a while only to overflow at some future date. There is therefore an endless possibility of Year 2000 type problems and it also complicates the code to have to constantly check for overflow, with resulting bugs from that code.
1. Google didn't use JavaME. They rolled their own. That takes time. Not to mention the development time in building a phone, then changing course and revamping the design when the iPhone launched.
2. I could say that OS X wasn't designed for a phone either. I'm sure the Rhapsody teams were really focused on mobile in 1997. And Java is still used in servers because server architectures are not homogeneous. You might need to run on POWER (AIX), SPARC (Solaris), PA-RISC (HP/UX), Itanium (Windows or Linux) or Intel (Windows or Linux). So it makes sense there. The desktop is one environment...x86. So writing a native application will run faster and deploy most everywhere, especially since most people aren't running Java on the desktop.
3. Flash had a lot of design problems limiting its success on mobile. I think it's safe to say that Google has been pretty successful on the whole Dalvik thing.
5. The reason while app sales in the Android universe are lousy (versus free apps) is because Android customers are poor customers in general. Once they buy a phone, they don't like opening their wallets for anything else. And they are much more likely to pirate a release.
2. The nice thing about NeXTSTEP kernel was that it DID run on most of those platforms you listed;-), and was pretty full functioned as a microkernel. It moved up to OSX nicely, but it's still there. Moving to ARM and then building a new UI on top of that (not using OSX's APIs and forcing it into a small 1/2GB RAM footprint. It may have not been designed for smartphones, but it was a microkernel from the CMU days, and therefore wasn't like an NT based solution (or a Linux+Interpreter) where there are
4. again, Google is focussed on maintaining visibility and viability of their revenue touch points. They saw that Apple was really spinning towards a fully closed system (absorbing of key services, such as search or ads or maps or email). This is less about keeping up, and more about keeping eyeballs on googles revenue streams… But I do think #5 is where google is failing
5. Google's PROBLEM is that they are getting the wrong eyeballs because of the Android model. Giving away an OS to phone makers is a race to the bottom for 'cheap' phones. Yeah a couple huge tech phones are released, but to sell a 3 year old phone that has fully amortized it's R&D (pure profits) is not a Google decision, but a carrier/HWbuilder problem. Eventually, the are getting the 'cheap' eyeballs, those who want to do 'one thing' that their feature phone did, but it's not sold anymore (say, calendaring and contact list sync). Why buy anything else?
I'm glad I'm not the only one that reacts to DEDs articles that way. I have big problems with reading most of his articles. I could be standing in a stock yard and not be surrounded with so much BS.
I'm interested in reading a good honest article about 64-bit and what this means for Apple vs Windows vs Android, unfortunately this DED guy is really crazy and I can't trust a single word he says. Actually I just couldn't read more than a few paragraphs. He makes me sick.
All you really have to do is look at where Mac OS is today. Basically it is all 64 bit and that gives Apple a stable platform for APIs and he like for a decade or more.
Initially that is what 64 bit will bring to iOS, a stable platform for APIs. This means that going forward they can concentrate on features, performance and other things instead of the complexity of multiple APIs. The next advantage will be more addressable memory, it isn't the 4GB barrier either that some allude to. Rather it has to do with the I/O memory map and how that 4GB / 32 bit address space gets split up. Of course we don't have specifics on this hardware design but it will now be possible to use all RAM installed even if it is less than 4GB.
It really isn't an issue of Apple vs XYZ. Everybody will eventually move to 64 bits so even if people try to twist the discussion around the competition with Android, it really isn't as important as it is to Apples future with iOS. 64 bit removes obstacles to evolving iOS in the way Apple wants too. This is perhaps the biggest deal with this 64 bit transition. 64 bit effectively frees Apple from past limits on iOS devices.
Google is currently working on Android 4.4, soon to be released. They've announced 5.0, and are obviously working on it. Whether they've already made it 64-bit, or will make it for the final release, is totally irrelevant.
Sure it is irrelevant but not because of what you think. The fact is Apple is on a different path than Android, Android could stay 32 bits forever and it wouldn't matter for either platform. Android won't of course for the same reason Apple hasn't, and that is because it is an excessive limitation for the platform.
As I said in an earlier post:
If 64-bit is insignificant, why did Samsung CEO pledged 64-bit support? Why would be Google making Android 64-bit? RAM? <span style="line-height:1.4em;">Most Personal Computers do just fine with 4GB RAM. Running MacOS X or say latest Fedora Linux (with KDE) requires less than 2GB in general.
That idea that Mac OS runs fine on just 2GB is false and obviously so. It has been well known for years now that 2GB is a minimal allotment of RAM for Mac OS.
</span>
<span style="line-height:1.4em;">Most high-end Android devices compete on specs, and that's </span>
why they <span style="line-height:1.4em;">pack 3GB of RAM. So, that's a barrier reached due to that being possible (and looks nice on a spec sheet), not because of necessity.</span>
While I can't argue that Androids are often sold to the spec obsessed, the funny thing here is that most of those phones are terrible performers compared to iPhones. Some people seem to not grasp the difference between real world usability and performance vs the spec sheet. As to necessity you do mis one thing, in the beginning Android phones actually did need that extra RAM verses the iPhone to work correctly.
... Google itself is turning its attention to Chrome, rather than doubling down on Andy Rubin's Android-centric strategy, which so far has primarily amassed significant legal problems related to its cavalier approach to intellectual property and built the company a fan base of users who don't like to pay for things, and in particular, software.
Not to mention amassing the $12.5 billion boat anchor called "Motorola Mobility."
Yes, an integrated hardware + software business could help Google control their own destiny.
You know, like Apple. But that's only part of the story. You need vision and commitment.
PadBook? No way. A real laptop with a real OS though on ARM hardware would be nice indeed.
I agree the AppleTV is a platform that can use more power… but… an ARM iOS laptop… no Intel (and that $100+ tax on their chipset), and no Samsung. Sell it with either Mac OSX or iOS on it.
The "TAX" on those Intel chips is likely much higher than $100. It is hard to tell with the foundry business, but it likely costs Apple someplace between $25 and $50 for each A7 out the foundry door. Then you have to add fees for each chip paid to ARM, Imagination and other IP suppliers, in the end the max prices is probably around $75 so Apple could actually save $200 to $300 per machine. With other economies they could be selling an A7 based laptop for $500. Note that is $500 for a high quality machine.
...and everything Surface wanted to be but couldn't (you want desktop or mobile OS… Or even dual boot/emulation… yeah, we got it.)
I'm actually in line for the A7X iPad! It should be a huge step up from my iPad 3. However this would cool my interest in a A7X based laptop running Mac OSX. The reality is I use the iPad in ways different from a laptop, one doesn't necessarily replace the other. Oh by the way that ARM based laptop would have to be as open as the current I86 based laptops from Apple.
[...] While I can't argue that Androids are often sold to the spec obsessed, the funny thing here is that most of those phones are terrible performers compared to iPhones. Some people seem to not grasp the difference between real world usability and performance vs the spec sheet. [...]
The average Android user either lacked the negotiation skills to get an iPhone at their neighborhood cell phone store or simply didn't know any better. To them, the bigger number is always better, so 64-bits trumps 32-bits. Boom.
The average Android troll on Apple Insider previously had only two angles from which to attack Apple: technical specs and "market share." But no longer. The tech spec angle is nearly gone. Android trolls have totally switched from attacking Apple with meaningless specs to desperately trying to spin the A7's superior specs and performance. They're so shell shocked that they've nearly forgotten the old third-world "big screen" angle. And it will be months before they can resume that tactic, with the inevitable cascade of iPhone 5C news: unboxing porn, first impression reviews, extremely impressive benchmarks, iOS 7 reviews, huge sales figures, and then the inevitable holiday season sales spike. Try spinning all of that.
No, the Android vs. iPhone spec war is over. iPad will soon be 64-bit capable as well, with the A7X. Boom.
Oh, and as for the Android troll "market share" angle, some share is worth more than other share.
To be fair, iOS was also designed initially for low-memory low-powered devices like the original iPhone. Moreover, it debuted mainly as a platform for web apps, and only later were provisions for third-party apps added in.
To be correct, Apple released iOS before it was mature and its OS X underpinning fully ported, thus the reason for not having fully mature APIs and modest power allocation, not because it ever was by design.
First, on the advantages of 64 bit to iOS, most of the analysis focuses on features of the 64 bit chip that are unrelated to the fact that it is 64bit. You could have those same features on 32 bit. Hence it is really discussing the advantages of a 64 bit ARM in particular, not 64 bits.
There are a couple of advantages to 64bit that are barely mentioned: faster at high precision math, and faster at handling >4GB memory in a single application.
Whoopee. For a few apps, the math is a big deal. In the future, >4GB memory will be of some interest.
The Android analysis gets an F- - it is extremely wrong.
I won't go into all the errors - it would take to much work.
Critically: the assertion is that it would be harder to port Android (and Android apps) to 64 bit. The opposite is true!
Porting Android requires porting *one* piece of code: dalvik. Applications don't have to even be touched, and there's no cost (unlike iOS) for using apps targeted at 32 bit.
If we were to believe the author's bizarre argument (apps aren't native code so they are harder to port), we'd have to turn upside down the whole reason people went to high level languages and VM's!
In fact, it is the apps that use native code (C) that might, depending on the app, require some porting if they were to run as 64 bit apps. This is just like *all* Objective C apps - every one has the potential to require code changes for 64 bit. Some will actually require it even though they don't need 64 bit at all.
The erst of the Android stuff may sound fine to Apple fan bois, but to those of use working in the Android space, it's just nonsense.
For Intel's x86, however, the move to 64-bit x86 processors also brought with it a solution to a long-standing issue of being "register starved," because the x86 family had originated as a 16-bit architecture that was incrementally enhanced into a 32-bit CPU. By the time 64-bit PCs arrived, the x86 design was nearly 25 years old.
Microsoft and Intel are literally made for each other. For decades, they've milked the corporate IT market with as little technological innovation as they though they could get away with. Instead of completely re-engineering their x86 processors (after having failed to persuade Microsoft to commit to a RISC version of Windows) Intel did the easy thing. They just bolted on a few improvements to x86, released the new compiler, forced PC makers to slap "Intel Inside" stickers on their sheet metal, and called it a day.
Meanwhile, Microsoft's last technical "innovation" was putting the NT kernel in a consumer OS. The result was Windows XP, which is still "good enough" for a huge chunk of Microsoft's corporate and home user base. And that was way back in 2001. They've trained a generation of Windows users to expect frustration, inconvenience, and poor taste. Corporate and home users won't upgrade a PC until they're forced to, and only because of malware infestation or hardware failure. So Microsoft isn't just attempting to fight Apple and Google. They're also wrestling with their own negative image. An image they've built since the early days of DOS.
So here we are. We're living in the post-PC, mobile, interconnected, ecosystem-integrated 21st century. And what are Microsoft and Intel doing? They're dribbling out incremental improvements to legacy Windows and x86. They're going through the motions of existing in the 21st century by releasing lifeless me-too products (Zune, KIN, Surface, Windows RT, Windows 8, and this year's iteration of legacy x86.)
Intel, to their credit, is seeing the light. The mindless "megahertz race" is over. Efficiency is the new battleground. Battery life trumps raw processing power, and Haswell is the proof. Too bad for Intel that no amount of optimization will make x86 work in iPhone clones or iPad clones. There's a trillion dollar mobile post-PC market out there, and it's out of both Microsoft's and Intel's reach. Far out of reach.
I realize common lore says Apple acquired NeXT and subsumed NeXTSTEP into Mac OS X. But it's more nuanced than that. Someone here, I believe, worked at NeXT and therefore could correct me.
SImple to look up. The original NeXTcube was a 25 MHz 68040. NeXTstep was designed around the Motorola 680x0 family and ported to Intel a few years later.
Comments
Android will have to move to 64-bit sooner or later, because some of the high end devices have RAM creeping uncomfortably close to 4gb. The Moto X, Nexus 7, and pretty much every other flagship phone or tablet all have 2gb RAM. The Galaxy Note 3 has 3gb RAM. A transition to 64 bit would happen primarily for memory reasons, not for some magic performance increase.
I don't argue the fact. I argue the attempts to downplay Apple's move to 64-bit architecture and it's benefits.
Here is something to think about:
The 32-bit Windows Server 2000 Datacenter Edition could address up to 256GB RAM. How did they do it? 48-bit addressing (effectively using 38-bit physical address lane), similar to the way the Intel 80286 (16-bit) processor was capable of addressing up to 16MB RAM (24-bit addressing; 16-bit allows for only 64KB).
The 32-bit/4GB barrier could be crossed by paging the RAM in multiple 4GB pages. That, of course, requires OS support. In such a scenario, the OS could support more than 4GB RAM. Each application will be restricted to 4GB linear address space, but multiple applications could be hosted in different areas utilising all the available memory. Programs that require more RAM, should support paging.
So, 64-bit architecture is NOT a requirement for supporting more than 4GB of RAM. Due to the complications around paging+memory virtualization in the software and system libraries, however, that approach is generally avoided.
I'm interested in reading a good honest article about 64-bit and what this means for Apple vs Windows vs Android, unfortunately this DED guy is really crazy and I can't trust a single word he says. Actually I just couldn't read more than a few paragraphs. He makes me sick.
It's not easy to explain when and how 64-bit are good or bad.
Often 64-bit architectures are presented using concepts valid many years ago, when 16-bit was cutting edge. In those years 16-bit CPUs basically had a 16-bit memory bus, a 16-bit instruction set, 16-bit internal data paths, 16-bit internal registers, 16-bit arithmetic logic units, 16-bit address space.
Modern 32-bit CPUs are quite different. External memory bus could be 64-bit or more, instruction set is much more complex and has SIMD extensions capable of handling vectors of data (not a single 32-bit number), internal data paths are insanely large, internal registers are definitely bigger than 32-bit, there are multiple ALUs of different kinds with SIMD capabilities. And some 32-bit CPUs are capable of handling more than 4GB of RAM through PAE support (basically an artificial extension of the addressing bits).
So, what is a 64-bit CPU ? 64-bit is basically a reference to the addressing space, pointers to memory locations have that size.
Advantage) 64-bit CPUs allows to natively address more than 2^32 = 4GB of RAM. Note that some 32-bit architectures have physical address extensions (PAE) to partially address this 32-bit limitation.
Advantage) Even if only 4GB (or less) are present, the 64-bit CPU still has a 64-bit virtual address space, that allows much more flexibility in memory mapping of large datasets (numerical analysis, movie and image processing, ...)
Disadvantage) Extending internal registers and path to support 64-bit address space has a small cost in term of silicon area and power consumption.
Myth) 64-bit CPUs do not have double processing power with respect to 32-bit one with the very same Arythmetic Logic Unit. Remember that 64-bit are only for the address space, the internal number crunching units are not changed by 32-bit to 64-bit transition.
Myth) While 32-bit means 2^32 = 4 GB support, this is not true for 64-bit. Current 64-bit architectures do not support 2^64 = huge_amount of memory. For example AMD64 architecture supports only 2^48 = 256TB of physical RAM, reserving remaining bits for improvement in the future. I am not sure about ARMv8, but I think 2^39.
Sorry for the wall of text. I hope it can help to clarify some marketing techno-bubbles.
http://iphone-inventory.blogspot.ca/2013/09/why-analysts-are-wrong-about-iphone-5c.html
It's about riding the launch hype and using the "Halo-Effect" to sell 5C devices.
Look at it this way even if it takes two more years to get to 14nm Apple already has the infrastructure in place to leverage the advantages those shrinks will provide. It also means that Apple will target 14nm with an enhanced or updated 64 bit complex rather than their first effort at 64 bit. They will have intrinsic knowledge of where the processor and support electronics need to be improved to best support iOS and its apps. In simple terms 64 bit is huge for Apple and its users and has put them well ahead of the pack. Many RIM engineers where in fact on record expressing disbelief that Apple was able to pull off what they did with iPhone 1. That just highlights the lack of forward thinking or the ability to grasp where silicon process shrinks are taking us. It literally is the same non sense all over again. Who cares? Really people see Android as Apples competition here but I don't think that is actually the whole ball of wax. Apple is really going after established PC architectures here, Windows and the like. I was reluctant to believe in the post PC era but I do believe they are onto something here. IOS, iPad and iPhone are just starting to mature to the point where they are good enough to truly impact the PC world. 64 bit hardware just removes one obstical in that undermining of the PC world.
64-bit viruses and malware
well, we certainly have dueling"experts" here today. but it all comes down to this:
- either Google ships a finished 64 bit version of Android in 2014 (not yet another pure hype test beta) along with upgraded Google apps for both smartphones and tablets, or it doesn't.
- if yes, either that 64 bit Android actually improves performance and/or supports new features, or it doesn't.
- if it does, either those 64 bit chipset high-end Android smartphones/tablets sell well in direct competition with the iPhone/iPad, or they don't.
- if they do, either developers also produce updated 64 bit apps for them, including tablet versions, or they don't.
- and if they do, either those owners actually buy those upgraded apps, or they don't.
there are a whole lot of "doesn'ts/don'ts" on this list - and like Sam Spade said, "look at the number of them." and then ...
- in any event, either Samsung formally forks its version of Android away from Google and/or launches Tizen, either with 64 bit, or it doesn't.
- either Google sidetracks Android (still at 32 bit?) and applies Chrome OS to its own brand of smartphones as its future priority, or it doesn't.
i wish there was a way to bring this thread back a year from now, where we could nail down which "expert" got it right - and how everything 64 bit actually turned out.
but what we do know for sure now is:
- Apple is shipping 64 bit iPhones today with upgraded Apple apps, with iPads sure to follow next month.
- This already improves performance and supports new features (like the major advances in the camera app).
- They will sell 100+ million 64 bit iPhones/iPads in the next year.
- so developers will rush to produce upgraded/enhanced 64 bit apps for iPhone/iPad, because ...
- iPhone/iPad owners will pay for noticeably enhanced apps.
basically, everything the Android fan people here are saying boils down to "coulda, woulda, shoulda." but the truth is, Apple just cleaned Android's clock, and they know it.
OK, enlighten me as to what is going to be in Android 5.0 then?
Have a break, have a KitKat
In defense of Apple, 64 bits and the A7 processor
There is a lot of confusion about why Apple decided to go to a 64 bit ARMv8 architecture for their A7 processor in the iPhone 5S. There is also a lot of doubt about their claim of double CPU performance. I know that 64 bit is essential for further progress in mobile computing and expect that the double performance claim will prove to be accurate. Here is why.
Let's start with the performance claim. The A7 processor has twice the floating point and general purpose registers. This means it can perform math a lot faster. The problem is that in order to fully utilize these new abilities you need to compile code that takes full advantage of it. That code cannot run on earlier processors so you also need a fat binary to support earlier iOS devices. Until a developer compiles their app with 64 bit support they won't see a big speed increase (perhaps the 30% seen in earlier reports). It is not the 64 bit that is giving the 2x speed, it is the code compiled for the A7's new instruction set.
So why 64 bits? After all the iPhone 5S has just 1GB of RAM which is much less than the 4GB address limit for a 32 bit app. As it turns out the address space is the biggest limitation for a 32 bit app not the RAM size. iOS has a fully featured operating system and can read large files by addressing them as if they were loaded into memory. This trick allow apps to make optimum use of the available RAM (which is less than 512MB) by using the operating system's ability to keep around just the pages that are in use and load others as they are needed. The problem is that it may not be possible to get large contiguous blocks of address space once it becomes fragmented. In addition the operating system itself is using a lot of the virtual address space for the various services it is providing to the app such as maps or the web browser.
64 bit solves all this by providing what may as well be an unlimited amount of address space. My own 3D mapping apps can now address their large map files as a single block of address space. The USA takes up about 6 GB at the best resolution. With 64 bit addressing, it would be possible to drive coast to coast without having to load any additional files because they would all be loaded into the virtual address space and then paged efficiently into the available RAM.
In the future you can expect to see amazing increases in flash memory performance. Apple will be able to blur the distinction between physical RAM and virtual address space. That means that apps will be able to allocate as much memory as there is available flash storage. This will make video editing, 3D rendering and other data intensive tasks traditionally performed on desktop computers possible to do on a tablet or even an iPhone.
This is my point: Don't treat the A7 processor and 64 bits lightly. Apple's processor group is firing on all cylinders and continues to amaze with 2x speed increases year after year at a time when Intel can barely squeeze out 5 or 10% speed increases on desktop CPUs. Samsung and the other smart phone makers must now scramble to catch up with the A7's advanced 64 bit architecture and blazing performance. The A7 with its dual cores will be out performing other processors with 8 cores and that performance will be visible in all apps not just the few that can take full advantage of many threads.
One of the underrated disasters of using 32-bit integers is that they are just big enough to work as counters for a while only to overflow at some future date. There is therefore an endless possibility of Year 2000 type problems and it also complicates the code to have to constantly check for overflow, with resulting bugs from that code.
1. Google didn't use JavaME. They rolled their own. That takes time. Not to mention the development time in building a phone, then changing course and revamping the design when the iPhone launched.
2. The nice thing about NeXTSTEP kernel was that it DID run on most of those platforms you listed;-), and was pretty full functioned as a microkernel. It moved up to OSX nicely, but it's still there. Moving to ARM and then building a new UI on top of that (not using OSX's APIs and forcing it into a small 1/2GB RAM footprint. It may have not been designed for smartphones, but it was a microkernel from the CMU days, and therefore wasn't like an NT based solution (or a Linux+Interpreter) where there are
4. again, Google is focussed on maintaining visibility and viability of their revenue touch points. They saw that Apple was really spinning towards a fully closed system (absorbing of key services, such as search or ads or maps or email). This is less about keeping up, and more about keeping eyeballs on googles revenue streams… But I do think #5 is where google is failing
5. Google's PROBLEM is that they are getting the wrong eyeballs because of the Android model. Giving away an OS to phone makers is a race to the bottom for 'cheap' phones. Yeah a couple huge tech phones are released, but to sell a 3 year old phone that has fully amortized it's R&D (pure profits) is not a Google decision, but a carrier/HWbuilder problem. Eventually, the are getting the 'cheap' eyeballs, those who want to do 'one thing' that their feature phone did, but it's not sold anymore (say, calendaring and contact list sync). Why buy anything else?
All you really have to do is look at where Mac OS is today. Basically it is all 64 bit and that gives Apple a stable platform for APIs and he like for a decade or more.
Initially that is what 64 bit will bring to iOS, a stable platform for APIs. This means that going forward they can concentrate on features, performance and other things instead of the complexity of multiple APIs. The next advantage will be more addressable memory, it isn't the 4GB barrier either that some allude to. Rather it has to do with the I/O memory map and how that 4GB / 32 bit address space gets split up. Of course we don't have specifics on this hardware design but it will now be possible to use all RAM installed even if it is less than 4GB.
It really isn't an issue of Apple vs XYZ. Everybody will eventually move to 64 bits so even if people try to twist the discussion around the competition with Android, it really isn't as important as it is to Apples future with iOS. 64 bit removes obstacles to evolving iOS in the way Apple wants too. This is perhaps the biggest deal with this 64 bit transition. 64 bit effectively frees Apple from past limits on iOS devices.
While I can't argue that Androids are often sold to the spec obsessed, the funny thing here is that most of those phones are terrible performers compared to iPhones. Some people seem to not grasp the difference between real world usability and performance vs the spec sheet. As to necessity you do mis one thing, in the beginning Android phones actually did need that extra RAM verses the iPhone to work correctly.
... Google itself is turning its attention to Chrome, rather than doubling down on Andy Rubin's Android-centric strategy, which so far has primarily amassed significant legal problems related to its cavalier approach to intellectual property and built the company a fan base of users who don't like to pay for things, and in particular, software.
Not to mention amassing the $12.5 billion boat anchor called "Motorola Mobility."
Yes, an integrated hardware + software business could help Google control their own destiny.
You know, like Apple. But that's only part of the story. You need vision and commitment.
Evidently Rubin's Android-centric vision didn't extend beyond patching legacy Android issues.
I'm actually in line for the A7X iPad! It should be a huge step up from my iPad 3. However this would cool my interest in a A7X based laptop running Mac OSX. The reality is I use the iPad in ways different from a laptop, one doesn't necessarily replace the other. Oh by the way that ARM based laptop would have to be as open as the current I86 based laptops from Apple.
[...] While I can't argue that Androids are often sold to the spec obsessed, the funny thing here is that most of those phones are terrible performers compared to iPhones. Some people seem to not grasp the difference between real world usability and performance vs the spec sheet. [...]
The average Android user either lacked the negotiation skills to get an iPhone at their neighborhood cell phone store or simply didn't know any better. To them, the bigger number is always better, so 64-bits trumps 32-bits. Boom.
The average Android troll on Apple Insider previously had only two angles from which to attack Apple: technical specs and "market share." But no longer. The tech spec angle is nearly gone. Android trolls have totally switched from attacking Apple with meaningless specs to desperately trying to spin the A7's superior specs and performance. They're so shell shocked that they've nearly forgotten the old third-world "big screen" angle. And it will be months before they can resume that tactic, with the inevitable cascade of iPhone 5C news: unboxing porn, first impression reviews, extremely impressive benchmarks, iOS 7 reviews, huge sales figures, and then the inevitable holiday season sales spike. Try spinning all of that.
No, the Android vs. iPhone spec war is over. iPad will soon be 64-bit capable as well, with the A7X. Boom.
Oh, and as for the Android troll "market share" angle, some share is worth more than other share.
One picture is worth a thousand words:
To be fair, iOS was also designed initially for low-memory low-powered devices like the original iPhone. Moreover, it debuted mainly as a platform for web apps, and only later were provisions for third-party apps added in.
To be correct, Apple released iOS before it was mature and its OS X underpinning fully ported, thus the reason for not having fully mature APIs and modest power allocation, not because it ever was by design.
First, on the advantages of 64 bit to iOS, most of the analysis focuses on features of the 64 bit chip that are unrelated to the fact that it is 64bit. You could have those same features on 32 bit. Hence it is really discussing the advantages of a 64 bit ARM in particular, not 64 bits.
There are a couple of advantages to 64bit that are barely mentioned: faster at high precision math, and faster at handling >4GB memory in a single application.
Whoopee. For a few apps, the math is a big deal. In the future, >4GB memory will be of some interest.
The Android analysis gets an F- - it is extremely wrong.
I won't go into all the errors - it would take to much work.
Critically: the assertion is that it would be harder to port Android (and Android apps) to 64 bit. The opposite is true!
Porting Android requires porting *one* piece of code: dalvik. Applications don't have to even be touched, and there's no cost (unlike iOS) for using apps targeted at 32 bit.
If we were to believe the author's bizarre argument (apps aren't native code so they are harder to port), we'd have to turn upside down the whole reason people went to high level languages and VM's!
In fact, it is the apps that use native code (C) that might, depending on the app, require some porting if they were to run as 64 bit apps. This is just like *all* Objective C apps - every one has the potential to require code changes for 64 bit. Some will actually require it even though they don't need 64 bit at all.
The erst of the Android stuff may sound fine to Apple fan bois, but to those of use working in the Android space, it's just nonsense.
For Intel's x86, however, the move to 64-bit x86 processors also brought with it a solution to a long-standing issue of being "register starved," because the x86 family had originated as a 16-bit architecture that was incrementally enhanced into a 32-bit CPU. By the time 64-bit PCs arrived, the x86 design was nearly 25 years old.
Microsoft and Intel are literally made for each other. For decades, they've milked the corporate IT market with as little technological innovation as they though they could get away with. Instead of completely re-engineering their x86 processors (after having failed to persuade Microsoft to commit to a RISC version of Windows) Intel did the easy thing. They just bolted on a few improvements to x86, released the new compiler, forced PC makers to slap "Intel Inside" stickers on their sheet metal, and called it a day.
Meanwhile, Microsoft's last technical "innovation" was putting the NT kernel in a consumer OS. The result was Windows XP, which is still "good enough" for a huge chunk of Microsoft's corporate and home user base. And that was way back in 2001. They've trained a generation of Windows users to expect frustration, inconvenience, and poor taste. Corporate and home users won't upgrade a PC until they're forced to, and only because of malware infestation or hardware failure. So Microsoft isn't just attempting to fight Apple and Google. They're also wrestling with their own negative image. An image they've built since the early days of DOS.
So here we are. We're living in the post-PC, mobile, interconnected, ecosystem-integrated 21st century. And what are Microsoft and Intel doing? They're dribbling out incremental improvements to legacy Windows and x86. They're going through the motions of existing in the 21st century by releasing lifeless me-too products (Zune, KIN, Surface, Windows RT, Windows 8, and this year's iteration of legacy x86.)
Intel, to their credit, is seeing the light. The mindless "megahertz race" is over. Efficiency is the new battleground. Battery life trumps raw processing power, and Haswell is the proof. Too bad for Intel that no amount of optimization will make x86 work in iPhone clones or iPad clones. There's a trillion dollar mobile post-PC market out there, and it's out of both Microsoft's and Intel's reach. Far out of reach.
Is that really true?
I realize common lore says Apple acquired NeXT and subsumed NeXTSTEP into Mac OS X. But it's more nuanced than that. Someone here, I believe, worked at NeXT and therefore could correct me.
SImple to look up. The original NeXTcube was a 25 MHz 68040. NeXTstep was designed around the Motorola 680x0 family and ported to Intel a few years later.