With 64 bit being no gain to existing smartphone users, its hard to envisage a fast open source led move to 64 bit. Here it is going to be harder to impose.
If all you're concerned with is memory address space, then there is no gain to existing smartphone users.
However, processors since the Pentium MMX have a concept called "single instruction, multiple data" or SIMD. This allows you to execute one instruction, and then load the pipe with datasets to have that instruction work on; rather than instruction - data - instruction - data. Being able to put two 32-bit values into a 64-bit register in an SIMD pipe allows you to crunch twice the data in one clock cycle.
And you know what uses SIMD incredibly efficiently? Video. Audio. Photos. Multimedia. The stuff people want to do with their high end phones these days.
So yeah, there's absolutely no gain on a smartphone to 64-bit processing. Or something.
It's not really overnight because there are very few apps that will take advantage of the processor. It's a move that future proofs the 5s so it'll will be relevant in 2 years time when all the iPhones that Apple sells will have a 64 bit processor, and that's the genius part of it.
In Xcode, the developer just needs to select the AArch64 target, and then fix any code that throws errors. Apple's done the "Fat Binary" thing three times now (MC68k > PowerPC, PowerPC > x86, x86 > x64) so of everyone out there, they know how to do the software bit in a seamless, transparent, and compatible fashion.
This transition won't take anywhere close to 2 years. I'd anticipate closer to 3 months.
If you wanted to release a 64bit android device, all you need is 64bit drivers for those components and you're good to go (which means compile android with armv8 as target architecture + make sure that you have libs for jni to ensure native code can be run in a 32bit compatibility environment).
Stop that, Android is not a linux kernel
linux is distributed as GPL2 android under a Apache-like license
Android has copied and changed the license (and seams that the GPL people has not said anything about that) of several header from linux for compatibility but is not linux that would be illegal.
So although I am sure it compile I am not so sure how well it has been tested in real hardware, as has been commented here, ARMv8 is still somewhat in flush, the full check of unsuspected bugs when running in specific implementation is difficult to gauge. Until final firm specification of the ARMv8,and firm Hardware design, that is expected for next year, a full testing of the compiler and the OS is not possible
That is and advantage at this point for Apple, it control the interpretation of the ARMv8 (see that Apple never call it ARMv8 so it not need to mach the ARMv8 specification) that is implemented, the hardware implementation, the compiler, the kernel, the APIs, the SDK and the development environment (XCODE).
Dalvik is not Java so the Dalvik VM need to be retested in the new ARMv8 hardware.
Apple control of the full environment allow it to run forward with an ARMv8 variant while the Android camp need to wait final ARMv8 specification, final hardware design, final hardware implementation, final gcc implementation final android kernel implementation, final Dalvik, and then began to test the apps.
Apple control of the full environment allow it to run forward with an ARMv8 variant while the Android camp need to wait final ARMv8 specification, final hardware design, final hardware implementation, final gcc implementation final android kernel implementation, final Dalvik, and then began to test the apps.
And when Google has transitioned Android to 64-bit, what incentive is there for smartphone HW makers to create a 64-bit chip?
linux is distributed as GPL2 android under a Apache-like license
Android has copied and changed the license (and seams that the GPL people has not said anything about that) of several header from linux for compatibility but is not linux that would be illegal.
Seriously, please educate yourself before making such assumptions.
- The kernel source is GPL2, as well as the additions from the android team (just watch the kernel upstream, quite a lot new code from google made it to 3.x versions of the kernel)
- AOSP "Android Open Source Project" is under an Apache license (minus the kernel)
Read up on different layers of an operating system, esp. kernel vs. userland:
Seriously, please educate yourself before making such assumptions.
- The kernel source is GPL2, as well as the additions from the android team (just watch the kernel upstream, quite a lot new code from google made it to 3.x versions of the kernel)
- AOSP "Android Open Source Project" is under an Apache license (minus the kernel)
Read up on different layers of an operating system, esp. kernel vs. userland:
You are right I didn't fact check as much as I should. I have the mistaken idea that when the people say that Android is linux was like when the people says that OSX is BSD and is more like when people say is mach.
The reference to OS layer was a total waste of time. The one that clarify the question was:
And when Google has transitioned Android to 64-bit, what incentive is there for smartphone HW makers to create a 64-bit chip?
That easy, they would already been building them so they have bragging right against Apple
That's what I was thinking first, but later on thought it might sort of backfire, as they could be seen as 'too late'. Not in the sense that people already switched to the iPhone, but reactions could be "...now you're giving us 64-bit CPU".
well we have a lot of folks here speculating - since they have now way of really knowing - that Google will update Android to 64 bit "next time" without great difficulty and thus keep up with iOS' technical innovations.
actually, i believe them, to a point. Google "announced" Kit Kat last month as an obvious PR response to the imminent arrival of iOS 7, but provided no details or timetable. i suppose they wanted to wait see what Apple might have up its sleeve with the new iPhone, and now they know - 64 bit, the M7, and Touch ID.
i assume we will see Kit Kat in the first part of next year - maybe even a beta by the end of this year (Google loves betas to suck in the geeks) - with biometric ID support and something like the M7 capability. but i doubt very much it will be 64 bit - there are just way too many details to attend to even if the basics are in place now. so a 64 bit version of Kit Kat would likely follow in the second half of 2014. but hey, it's coming (so Apple's innovative is no big deal)!
but here is the kicker - most of the OEM's will stick with the 32 bit OS for most of their new models for some years, because the 64 bit chipsets are certainly going to be more expensive for some time, and cheap is what Android is most about, especially world wide. the major OEM's will no doubt release a 64 bit premium model too, but mainly for the PR. so you can buy that next snazzy 64 bit Nexus or Galaxy S? - but what exactly can you do with it?
because as a result of that, development/updates of 64 bit Android apps will happen much, much more slowly than iOS apps - Android apps buyers will continue to be almost all 32 bit handset owners (i bet even Google will take until 2015 to update all its apps), so it just won't be worth the trouble for them for a few years.
(whereas strong sales of millions of the new 64 bit iPhones and - no doubt - iPads too starting with the holiday season gives iOS app developers a big new market to sell "upgraded" 64 bit versions of their apps to owners who already have and like their 32 bit app - hopefully at less than full price. so developers of paid apps will certainly get to work on 64 bit upgrades ASAP. and Apple itself has already done this for its stable of apps.)
Judging from your 2 posts here you should go back to anandtech. Since this a stupid sight in your eyes. and if you actually read the article you would see that DED is quoting other people that DO know what there talking about, when talking about technical issues. He even quotes Brian Klug and Anand Lal Shimpi's reactions to the new A7 and they were impressed.
Why is there such a defensive reaction to feedback? I like Appleinsider's articles and think they generally do a good job. However, I do cringe sometimes when I see their writers try to make technical insights as this is not their strength.
You somewhat make my point - DED is quoting other sources without having their background. I'm not sure why you bring up the A7 as it is a very impressive chip - my point was about the process it's on which is objective, not subjective.
When I see wild suppositions in articles like this that TSMC could be building the A7 on 20nm node, frankly anyone with any process background or industry experience will know that's not occuring. That doesn' take away from the A7, but the author should be careful about throwing in info that's just wrong. It diminishes the rest of the article.
You know, for what it's worth, I think that the Exynos Octa has been a bit of a disaster so far. The first Octa (5410) had a cache coherency flaw that required the entire cache to be flushed every time it switched from the 4 big cores to the four little cores, or vice versa, which resulted in a major performance hit. But Samsung shipped it anyway:
Quote:
Samsung talked up the Exynos 5 Octa quite a lot when it was announced, but the SoCnever saw wide scale use beyond the international Galaxy S4. Part of the reason is that the Exynos is hard to manufacture, but there was also a troublesome bug in the CCI-400 coherent bus interface. Developers noticed the bizarre behavior caused by this issue, and Samsung was eventually forced to admit that coherence between the two CPU islands was disabled on the 5410. Basically, switching between the A15 and A7 cores caused all caches to be flushed from memory. That’s trouble for performance and battery life — both things big.LITTLE is supposed to improve.
Yes, Samsung's approach is certainly "if it's broke, we'll fix it in the next iteration", but that has led them to continuously innovate, like clockwork. You can expect an update from Samsung in a year, sometimes even less. But ultimately, if a feature is that important to you, make sure it is working when you buy the product from Samsung, as their support and backward compatibility track record is pretty poor.
It is stunning that Samsung would break quality and ship an obviously buggy product without offering a replacement.
?
...but they did, to Fandroids that were so eager to get an "octa" core processor, they didn't care it only ran 4 cores at once, and that its performance was hobbled.
A number of articles appeared since July that Samsung had "fixed" the problem with the new iteration of the Exynos Octa, the 5420.:
Quote:
It hasn't been much of a secret in the SoC space that big.LITTLE on the original Exynos 5 Octa (5410) didn't end up working in the most optimal fashion.
(Nice bit of understatement).
Trouble is, although Samsung has been puffing the redo with videos showing the new and improved Octa in operation to folks like Anandtech, it stillisn't shipping. And anyone who owns an existing Exynos Octa-containing device basically got screwed by Samsung.
I think i can now finally understand why the Android Camp hated us.
Please, take AI's technical analysis with a big gain of salt. Most of the issues with this "Editorial" are already addressed by many others. If you are interested in those, Anandtech is a good place to start with.
And please ignore most of these post on Software issues with 64bit codebase etc. Most of them are plain wrong.
So what exactly is so "disastrous" about Exynos again?
Please appleinsider - stick to what you're good at and don't try to write technical articles as your knowledge level is embarrassingly low.
From a process standpoint, the A7 is clearly using TSMC's 28nm process and packing 1 billion transistors onto a100mm2 die is not impressive *from a process standpoint*. It clearly is an impressive chip overall and it's new functionality is great. However comparing it to pure-CPUs frankly demonstrates ignorance, as integrated GPUs blow up transistor counts and have higher density than CPUs.
At 28nm, assuming the A7 is approx 500 million transistors GPU and 500 million transistors non-gpu, the GPU portion would be about 40mm^2 and it would occupy about 40% of the total die. The non-gpu portion would be around 60mm^2 (50% more area per transistor, which sounds about right.) When apple moves to a 100mm^2 die on 20nm, it will have 1.4billion transistors or more.
Frankly Intel is the only company with a clear process advantage as TSMC's upcoming 22nm process will still be behind Intel's now somewhat outdated 22nm node as they lack FinFETs and Intel is releasing products at 14nm.
If you want great technical reviews - go to anandtech - right now they're one of the few places you can go to and really trust their reviews and editorials.
Last note - I'm not sold on the big.LITTLE arch (as clearly Qualcomm is not). However with Samsung and other OEMs releasing devices that now have HMP, it'll be interesting purely from a technical exercise if it really does improve the race to idle as well as non-intensive power usage. Whether the overall BOM increase of $7.75 of the Exynos-powered S4 vs the Qualcomm-powered S4 makes a material difference it up for question (once you remove the extra battery and box contents of the international S4).
Your first paragraph is a contemptuous insult, grieviously condescending.
Your last paragraph is pure gibberish, jargon flaunted only for effect, with no regard for communicating in plain English. No subject is so complicated that it can't be translated into plain English for those with little or no familiarity with the trade being discussed.
So don't be surprised if your critical post isn't received with gratitude. Everybody needs an editor. DED does, I do, and you really do. It was too hard to read what you said.
This is what happened. Keep in mind, this is all conjecture on my part.
Apple placed an order with Samsung for A6 chips for use with the 5C, while simultaneously (and quietly) placing an order with TSMC for A7 chips for use with the 5S. Samsung probably assumed the A6 chips they were producing for Apple were for the 5S and probably assume the 5C would use the A5 (as earlier 5C rumors indictated). If this is true, I'm surprised they wouldn't do a double-take and question their assumption that the 5S wouldn't include a processor upgrade.
I'm assuming Apple, in the immediate future, will not replace Sumsung as a chip supplier. They just won't give Samsung newer chip fabrication jobs. Assuming the iPhone 6 is announced next September, I'm assuming it will have an A8 chip fabricated by TSMC. Next September's iPhone product announcements would also include an inexpensive version of the 5S (6C?) and include an A7 chip fabricated by Samsung.
You really think they can design a 64 bit ARM processor from scratch in 6 weeks? Get serious...
You so desperately want to give Samsung points for allegedly starting first? Even if you could prove that assertion, it doesn't matter. They don't give Olympic Gold Medals for starting a competition. Apple finished first. Apple shipped first. Apple got iOS7 and apps ported first. Apple customers can buy it this Friday.
And feel free to post any credible citation that says Kit Kat is (not some rumored to be or someone's opinion that, but is) 64-bit, because if it isn't, it won't matter what Samsung ships next Feb/Mar.
You really think they can design a 64 bit ARM processor from scratch in 6 weeks? Get serious...
Samsung had ample opportunity to include 64 bit processing in their next flagship product, the Note 3, announced a few weeks ago and launching "sometime in October".
The fact they didn't say a word proves beyond any doubt that Apple's announcement caught them completely flat footed.
Hum and har as much as you want, all your conjecture is bullshit.
I like iWork, especially KeyNote, but for Enterprise use, Pages and Numbers aren't really a big deal, they're pretty, but the biggest feature for Enterprise users is collaboration and backoffice, and iWork basically doesn't compete with Google Docs or Office in that regard, and I'm not sure Pages and Numbers are a big draw for consumers.
Who mentioned Enterprise use? iWork is a bargain for the power and ease of use and does what almost the majority of users want I'd imagine. When MS Office is available on Android or a Windows phone then I suppose there may be some competition! Word and Excel have power and difficulty way beyond what most home (and office, come to that) users require. The individual iWork apps were the top three highest grossing apps on the App Store for ages after their release so they're clearly extremely popular.
Since no one should have to slog through that drivel, I’ll summarize.
“Android can already do 64-bit because Android is Linux and Linux can do 64-bit.” Transitive property of equality works in geometry, not here, bucko.
“64-bit was inevitable, therefore Apple making a 64-bit phone isn’t anything special. The industry was always going to be 64-bit.” Get bent with your 'natural progression’ BS.
Originally Posted by ruel24
You really think they can design a 64 bit ARM processor from scratch in 6 weeks? Get serious...
Your link reads exactly like that FUD-filled post from the other guy. Zero evidence they’re actually working on 64-bit in Android (rather, obviously they are now because Apple has already completed said work, but before that). And yes, I do believe they can build such a processor that quickly, as apparently Samsung is the reason Apple was even able to make the iPhone at all in the first place. Such a marvelous company with such a history of innovation and chipmaking shouldn’t have any trouble doing what they’ve been claimed to have been doing for “a while now anyway”.
Comments
If all you're concerned with is memory address space, then there is no gain to existing smartphone users.
However, processors since the Pentium MMX have a concept called "single instruction, multiple data" or SIMD. This allows you to execute one instruction, and then load the pipe with datasets to have that instruction work on; rather than instruction - data - instruction - data. Being able to put two 32-bit values into a 64-bit register in an SIMD pipe allows you to crunch twice the data in one clock cycle.
And you know what uses SIMD incredibly efficiently? Video. Audio. Photos. Multimedia. The stuff people want to do with their high end phones these days.
So yeah, there's absolutely no gain on a smartphone to 64-bit processing. Or something.
It's not really overnight because there are very few apps that will take advantage of the processor. It's a move that future proofs the 5s so it'll will be relevant in 2 years time when all the iPhones that Apple sells will have a 64 bit processor, and that's the genius part of it.
In Xcode, the developer just needs to select the AArch64 target, and then fix any code that throws errors. Apple's done the "Fat Binary" thing three times now (MC68k > PowerPC, PowerPC > x86, x86 > x64) so of everyone out there, they know how to do the software bit in a seamless, transparent, and compatible fashion.
This transition won't take anywhere close to 2 years. I'd anticipate closer to 3 months.
Where did you get that information from?
I really think you're way off here.
Google is testing Linux Kernel 3.7+ since january and already published release candidates with armv8 support:
https://android.googlesource.com/kernel/common/+/experimental/android-3.10-rc5/arch/arm64/
If you wanted to release a 64bit android device, all you need is 64bit drivers for those components and you're good to go (which means compile android with armv8 as target architecture + make sure that you have libs for jni to ensure native code can be run in a 32bit compatibility environment).
Stop that, Android is not a linux kernel
linux is distributed as GPL2 android under a Apache-like license
Android has copied and changed the license (and seams that the GPL people has not said anything about that) of several header from linux for compatibility but is not linux that would be illegal.
So although I am sure it compile I am not so sure how well it has been tested in real hardware, as has been commented here, ARMv8 is still somewhat in flush, the full check of unsuspected bugs when running in specific implementation is difficult to gauge. Until final firm specification of the ARMv8,and firm Hardware design, that is expected for next year, a full testing of the compiler and the OS is not possible
That is and advantage at this point for Apple, it control the interpretation of the ARMv8 (see that Apple never call it ARMv8 so it not need to mach the ARMv8 specification) that is implemented, the hardware implementation, the compiler, the kernel, the APIs, the SDK and the development environment (XCODE).
Dalvik is not Java so the Dalvik VM need to be retested in the new ARMv8 hardware.
Apple control of the full environment allow it to run forward with an ARMv8 variant while the Android camp need to wait final ARMv8 specification, final hardware design, final hardware implementation, final gcc implementation final android kernel implementation, final Dalvik, and then began to test the apps.
And when Google has transitioned Android to 64-bit, what incentive is there for smartphone HW makers to create a 64-bit chip?
And when Google has transitioned Android to 64-bit, what incentive is there for smartphone HW makers to create a 64-bit chip?
That easy, they would already been building them so they have bragging right against Apple
Stop that, Android is not a linux kernel
linux is distributed as GPL2 android under a Apache-like license
Android has copied and changed the license (and seams that the GPL people has not said anything about that) of several header from linux for compatibility but is not linux that would be illegal.
Seriously, please educate yourself before making such assumptions.
- The kernel source is GPL2, as well as the additions from the android team (just watch the kernel upstream, quite a lot new code from google made it to 3.x versions of the kernel)
- AOSP "Android Open Source Project" is under an Apache license (minus the kernel)
Read up on different layers of an operating system, esp. kernel vs. userland:
http://en.wikipedia.org/wiki/User_space
Seriously, please educate yourself before making such assumptions.
- The kernel source is GPL2, as well as the additions from the android team (just watch the kernel upstream, quite a lot new code from google made it to 3.x versions of the kernel)
- AOSP "Android Open Source Project" is under an Apache license (minus the kernel)
Read up on different layers of an operating system, esp. kernel vs. userland:
http://en.wikipedia.org/wiki/User_space
You are right I didn't fact check as much as I should. I have the mistaken idea that when the people say that Android is linux was like when the people says that OSX is BSD and is more like when people say is mach.
The reference to OS layer was a total waste of time. The one that clarify the question was:
http://source.android.com/source/licenses.html
That's what I was thinking first, but later on thought it might sort of backfire, as they could be seen as 'too late'. Not in the sense that people already switched to the iPhone, but reactions could be "...now you're giving us 64-bit CPU".
I actually feel sorry for Samsung.
...and it's gone...
well we have a lot of folks here speculating - since they have now way of really knowing - that Google will update Android to 64 bit "next time" without great difficulty and thus keep up with iOS' technical innovations.
actually, i believe them, to a point. Google "announced" Kit Kat last month as an obvious PR response to the imminent arrival of iOS 7, but provided no details or timetable. i suppose they wanted to wait see what Apple might have up its sleeve with the new iPhone, and now they know - 64 bit, the M7, and Touch ID.
i assume we will see Kit Kat in the first part of next year - maybe even a beta by the end of this year (Google loves betas to suck in the geeks) - with biometric ID support and something like the M7 capability. but i doubt very much it will be 64 bit - there are just way too many details to attend to even if the basics are in place now. so a 64 bit version of Kit Kat would likely follow in the second half of 2014. but hey, it's coming (so Apple's innovative is no big deal)!
but here is the kicker - most of the OEM's will stick with the 32 bit OS for most of their new models for some years, because the 64 bit chipsets are certainly going to be more expensive for some time, and cheap is what Android is most about, especially world wide. the major OEM's will no doubt release a 64 bit premium model too, but mainly for the PR. so you can buy that next snazzy 64 bit Nexus or Galaxy S? - but what exactly can you do with it?
because as a result of that, development/updates of 64 bit Android apps will happen much, much more slowly than iOS apps - Android apps buyers will continue to be almost all 32 bit handset owners (i bet even Google will take until 2015 to update all its apps), so it just won't be worth the trouble for them for a few years.
(whereas strong sales of millions of the new 64 bit iPhones and - no doubt - iPads too starting with the holiday season gives iOS app developers a big new market to sell "upgraded" 64 bit versions of their apps to owners who already have and like their 32 bit app - hopefully at less than full price. so developers of paid apps will certainly get to work on 64 bit upgrades ASAP. and Apple itself has already done this for its stable of apps.)
Ain't even more fragmentation great?!
chew on that, android fan people.
Judging from your 2 posts here you should go back to anandtech. Since this a stupid sight in your eyes. and if you actually read the article you would see that DED is quoting other people that DO know what there talking about, when talking about technical issues. He even quotes Brian Klug and Anand Lal Shimpi's reactions to the new A7 and they were impressed.
Why is there such a defensive reaction to feedback? I like Appleinsider's articles and think they generally do a good job. However, I do cringe sometimes when I see their writers try to make technical insights as this is not their strength.
You somewhat make my point - DED is quoting other sources without having their background. I'm not sure why you bring up the A7 as it is a very impressive chip - my point was about the process it's on which is objective, not subjective.
When I see wild suppositions in articles like this that TSMC could be building the A7 on 20nm node, frankly anyone with any process background or industry experience will know that's not occuring. That doesn' take away from the A7, but the author should be careful about throwing in info that's just wrong. It diminishes the rest of the article.
You know, for what it's worth, I think that the Exynos Octa has been a bit of a disaster so far. The first Octa (5410) had a cache coherency flaw that required the entire cache to be flushed every time it switched from the 4 big cores to the four little cores, or vice versa, which resulted in a major performance hit. But Samsung shipped it anyway:
From AnandTech comments (my emphasis):
Sivar - Tuesday, July 23, 2013 - link
Not at all.Remember Samsung Galaxy S? It shipped with an obviously broken GPS. No replacement offered.
Remember the Galaxy X III and its rash of mainboard failures?
Remember the class action lawsuit over Samsung LCD TV failures? Their refrigerators?
This is par for Samsung.REPLY
steven75 - Tuesday, July 23, 2013 - link
Part of the problem with Samsung's "throw everything at the wall and see what sticks" approach is that some of it *won't* stick.REPLYchizow - Thursday, July 25, 2013 - link
Yes, Samsung's approach is certainly "if it's broke, we'll fix it in the next iteration", but that has led them to continuously innovate, like clockwork. You can expect an update from Samsung in a year, sometimes even less. But ultimately, if a feature is that important to you, make sure it is working when you buy the product from Samsung, as their support and backward compatibility track record is pretty poor.jameskatt - Friday, August 16, 2013 - link
It is stunning that Samsung would break quality and ship an obviously buggy product without offering a replacement.?
...but they did, to Fandroids that were so eager to get an "octa" core processor, they didn't care it only ran 4 cores at once, and that its performance was hobbled.
A number of articles appeared since July that Samsung had "fixed" the problem with the new iteration of the Exynos Octa, the 5420.:
(Nice bit of understatement).
Trouble is, although Samsung has been puffing the redo with videos showing the new and improved Octa in operation to folks like Anandtech, it still isn't shipping. And anyone who owns an existing Exynos Octa-containing device basically got screwed by Samsung.
I think i can now finally understand why the Android Camp hated us.
Please, take AI's technical analysis with a big gain of salt. Most of the issues with this "Editorial" are already addressed by many others. If you are interested in those, Anandtech is a good place to start with.
And please ignore most of these post on Software issues with 64bit codebase etc. Most of them are plain wrong.
So what exactly is so "disastrous" about Exynos again?
So what exactly is so "disastrous" about Exynos again?
Clue: read comment directly above yours.
Source? I find zero information stating that.
Proof? Given Samsung’s past devices, I would be surprised if they had longer than a six week turnaround in designing a new one.
http://liliputing.com/2013/09/android-ready-64-bit-processing.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+Liliputing+(Liliputing)
You really think they can design a 64 bit ARM processor from scratch in 6 weeks? Get serious...
Your first paragraph is a contemptuous insult, grieviously condescending.
Your last paragraph is pure gibberish, jargon flaunted only for effect, with no regard for communicating in plain English. No subject is so complicated that it can't be translated into plain English for those with little or no familiarity with the trade being discussed.
So don't be surprised if your critical post isn't received with gratitude. Everybody needs an editor. DED does, I do, and you really do. It was too hard to read what you said.
Apple placed an order with Samsung for A6 chips for use with the 5C, while simultaneously (and quietly) placing an order with TSMC for A7 chips for use with the 5S. Samsung probably assumed the A6 chips they were producing for Apple were for the 5S and probably assume the 5C would use the A5 (as earlier 5C rumors indictated). If this is true, I'm surprised they wouldn't do a double-take and question their assumption that the 5S wouldn't include a processor upgrade.
I'm assuming Apple, in the immediate future, will not replace Sumsung as a chip supplier. They just won't give Samsung newer chip fabrication jobs. Assuming the iPhone 6 is announced next September, I'm assuming it will have an A8 chip fabricated by TSMC. Next September's iPhone product announcements would also include an inexpensive version of the 5S (6C?) and include an A7 chip fabricated by Samsung.
http://liliputing.com/2013/09/android-ready-64-bit-processing.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+Liliputing+(Liliputing)
You really think they can design a 64 bit ARM processor from scratch in 6 weeks? Get serious...
You so desperately want to give Samsung points for allegedly starting first? Even if you could prove that assertion, it doesn't matter. They don't give Olympic Gold Medals for starting a competition. Apple finished first. Apple shipped first. Apple got iOS7 and apps ported first. Apple customers can buy it this Friday.
And feel free to post any credible citation that says Kit Kat is (not some rumored to be or someone's opinion that, but is) 64-bit, because if it isn't, it won't matter what Samsung ships next Feb/Mar.
Samsung had ample opportunity to include 64 bit processing in their next flagship product, the Note 3, announced a few weeks ago and launching "sometime in October".
The fact they didn't say a word proves beyond any doubt that Apple's announcement caught them completely flat footed.
Hum and har as much as you want, all your conjecture is bullshit.
I like iWork, especially KeyNote, but for Enterprise use, Pages and Numbers aren't really a big deal, they're pretty, but the biggest feature for Enterprise users is collaboration and backoffice, and iWork basically doesn't compete with Google Docs or Office in that regard, and I'm not sure Pages and Numbers are a big draw for consumers.
Who mentioned Enterprise use? iWork is a bargain for the power and ease of use and does what almost the majority of users want I'd imagine. When MS Office is available on Android or a Windows phone then I suppose there may be some competition! Word and Excel have power and difficulty way beyond what most home (and office, come to that) users require. The individual iWork apps were the top three highest grossing apps on the App Store for ages after their release so they're clearly extremely popular.
Since no one should have to slog through that drivel, I’ll summarize.
“Android can already do 64-bit because Android is Linux and Linux can do 64-bit.” Transitive property of equality works in geometry, not here, bucko.
“64-bit was inevitable, therefore Apple making a 64-bit phone isn’t anything special. The industry was always going to be 64-bit.” Get bent with your 'natural progression’ BS.
You really think they can design a 64 bit ARM processor from scratch in 6 weeks? Get serious...
Your link reads exactly like that FUD-filled post from the other guy. Zero evidence they’re actually working on 64-bit in Android (rather, obviously they are now because Apple has already completed said work, but before that). And yes, I do believe they can build such a processor that quickly, as apparently Samsung is the reason Apple was even able to make the iPhone at all in the first place. Such a marvelous company with such a history of innovation and chipmaking shouldn’t have any trouble doing what they’ve been claimed to have been doing for “a while now anyway”.