or Connect
AppleInsider › Forums › Mobile › iPhone › After its disastrous Exynos 5 Octa, Samsung may have lost Apple's A7 contract to TSMC
New Posts  All Forums:Forum Nav:

After its disastrous Exynos 5 Octa, Samsung may have lost Apple's A7 contract to TSMC - Page 7

post #241 of 366

Well that threw a cat in amongst the pigeons.

 

I learned a lot from this article. Incendiary, but completely brilliant and thoroughly researched. It really does show you how tech journalism has devolved into regurgitating press releases. People aren't thinking deeply, strategically or long term. 

 

I have always suspected Apple were playing the long game and Samsung were running a food fight; throwing mud and seeing what sticks. I didn't realise Samsung were not even taking the time to lay the foundations in their manufacturing division. I've felt for a while that Samsung is very much at risk of tripping over it's own short-sighted success. Too quick to grab this sale at the expense of the next ten. What happens when you run out of poorly-implemented ideas? What happens when your gimmicks start impacting adversely on battery life? How do you convince someone with a 6-inch phone to upgrade? Sell them a 7/8/9/10-inch phone? Sell adjunct accessories with no inherent reason for beingClearly their strategy has diminishing returns.

 

People will eventually tire of complicated, poorly-implemented gimmicks. And when they do Apple is ready to sell them a functional, integrated solution from a family of devices at the optimal crux of design, usability, features, battery life and cost.

 

Siri has been panned but I suspect it's a sleeper hit waiting to happen. Apple Maps was an uncomfortable move forced by Google withholding turn-by-turn data and wanting to implement steep charges for vendors accessing its map data. Though much maligned, Apple Maps was at least successful at manoeuvring Google to provide turn-by-turn data to iPhone users, which was the entire point.

 

Apple will soon build themselves into a position where the have the volume, proprietary hardware and power efficiency such that no one will be able to compete in terms of form-factor, battery life and, eventually, cost.

 

Some may argue that we are already there.

post #242 of 366

Java has always been 64-bit (long data types), and the Java VM has supported 64-bit addressing for years due to Java's use in the enterprise. Dalvik adheres to this spec and supports 64-bit data types and addresses. For application developers on Android, you won't even need to recompile software if it uses no native code, you'll get 64-bit use automatically once Dalvik is deployed at 64-bit.

 

But Dalvik runs on top of Linux, so the question is, is Linux 64-bit ready? Yes, it was the first consumer OS to be 64-bit, before Apple and Microsoft.  What is usually not 64-bit bit ready are proprietary binary device drivers that you can from Qualcomm, Nvidia, et al. 

 

But, there is evidence this isn't going to be a problem. The Android x86 project shipped Android running on 64-bit x86 AMD/Intel chips a long time ago and it works.

 

Android will have an easier time moving to 64-bit (for Java based software, not NDK software) precisely because it is virtualized. It's like asking when will Javascript sites work on 64-bit, and the answer is, as soon as the Javascript VM is modified to leverage it, everything will benefit automatically. The stuff about needing Oracle is utter nonsense. Oracle has nothing to do with Android's Java implementation, and Oracle's implementation of Java is already 64-bit capable and has been for years.

 

What I find interesting is, when Apple is not the first to market (multicores, bigger ram, bigger screens, etc), then "specs don't matter" and Apple is not "following", but when Apple is first, all of a sudden, specs are the most important thing in the world, and anyone who was thinking the same thing, but late out of the gate is a copycat.

 

The reality is, 64-bit was inevitable, as mobile phones are already within a factor of 4 of the upper RAM limit, and ARMv8 was specced out in 2011 and vendors licensed SoCs in 2012 with predictions of shipping in 2014. Apple made it first, but being first out of the gate isn't always best either. It's like when NVidia and ATI used to release ultra powerful GPUs, but no games could really leverage them to the fullest, because it would fragment the market against mostly everyone else who had lower end HW.  64-bit on the 5S is going to give only modest speedups for the time being, nothing like the 2x quoted.

 

What's missing from this cheery discussion is the effect that pushing bigger die sizes with more transistors and switching fabs has on yields. The iPhone 5s seems to indicating short supply, this is due to either the fingerprint sensor, the 64-bit CPU, or a combination of both. My guess is the A7 is having yield problems. TSMC is notorious for this, and NVidia and ATI which both used TSMC used to have to frequently respin their silicon when they started hitting +1billion trannies.  The more trannies and die area, the higher the probability of defects. 

 

Thus, the A7 may in fact be costing Apple delays in parts and margins, because the more bad chips that come off of a wafer, the worse the margins. When most of the industry goes 64-bit in 2014, no one's going to care that Apple was first, just like no one cared who had the first dual core, quad core, or octa-core. Consumers don't care, only fanboys do, so they can engage in continuous penis measuring contests.

 

The iPhone 5S confers no benefit in battery life. Imagine if instead of doubling the number of transistors, Apple had instead, used the new semiconductor process to end up with a fall smaller SoC, it would drain less power, and be cheaper, and battery life would be greater. The question needs to be asked, does the iPhone already perform well enough? Does it really need 2x more CPU? Will consumers really notice that, or maybe they'll notice 20 hr battery life instead of 10? It's like having the ability to design a car with 2x the HP or 2x the gas mileage.  Increasing the power isn't always  the best win, as we learned from the desktop, eventually there are marginal returns.

 

(I'm guessing I'll be banned for writing an article that speaks positively of Android and semi-critical of Apple, as it seems you can get banned by these forums for merely stating the facts, while other people spew downright nasty ad hominems and nothing ever seems to happen, as long as you tow the Apple party line, it seems criticizing Apple is too hurtful)

post #243 of 366
Quote:
Originally Posted by PhilBoogie View Post


If that's the case, then the majority won't get it before 2016/2017. Wow.
From reading that Android blog, it looks like it's mandatory to be stupid. Yes, Android. For the stupidities of us.

 

How can the majority get it in 2016/17?

 

The majority runs a several generations old Android at any time, I have 2 Andoids in my household, they were bought based on price only, and they are not close to running the latest version of A. I also have 2 iPhones (4 and 5), they obviously have always been fully up to date, but for the Androids that has never been an option.


Edited by RPT - 9/16/13 at 1:33am
post #244 of 366

This is quality in-depth and thinking person's writing. The hardware equivalent of a John Siracusa OS X analysis! :)

 

Keep it up please.

post #245 of 366
Quote:
Originally Posted by bitbyter View Post

Java has always been 64-bit (long data types), and the Java VM has supported 64-bit addressing for years due to Java's use in the enterprise. Dalvik adheres to this spec and supports 64-bit data types and addresses. For application developers on Android, you won't even need to recompile software if it uses no native code, you'll get 64-bit use automatically once Dalvik is deployed at 64-bit.

But Dalvik runs on top of Linux, so the question is, is Linux 64-bit ready? Yes, it was the first consumer OS to be 64-bit, before Apple and Microsoft.  What is usually not 64-bit bit ready are proprietary binary device drivers that you can from Qualcomm, Nvidia, et al. 

But, there is evidence this isn't going to be a problem. The Android x86 project shipped Android running on 64-bit x86 AMD/Intel chips a long time ago and it works.

Android will have an easier time moving to 64-bit (for Java based software, not NDK software) precisely because it is virtualized. It's like asking when will Javascript sites work on 64-bit, and the answer is, as soon as the Javascript VM is modified to leverage it, everything will benefit automatically. The stuff about needing Oracle is utter nonsense. Oracle has nothing to do with Android's Java implementation, and Oracle's implementation of Java is already 64-bit capable and has been for years.

What I find interesting is, when Apple is not the first to market (multicores, bigger ram, bigger screens, etc), then "specs don't matter" and Apple is not "following", but when Apple is first, all of a sudden, specs are the most important thing in the world, and anyone who was thinking the same thing, but late out of the gate is a copycat.

The reality is, 64-bit was inevitable, as mobile phones are already within a factor of 4 of the upper RAM limit, and ARMv8 was specced out in 2011 and vendors licensed SoCs in 2012 with predictions of shipping in 2014. Apple made it first, but being first out of the gate isn't always best either. It's like when NVidia and ATI used to release ultra powerful GPUs, but no games could really leverage them to the fullest, because it would fragment the market against mostly everyone else who had lower end HW.  64-bit on the 5S is going to give only modest speedups for the time being, nothing like the 2x quoted.

What's missing from this cheery discussion is the effect that pushing bigger die sizes with more transistors and switching fabs has on yields. The iPhone 5s seems to indicating short supply, this is due to either the fingerprint sensor, the 64-bit CPU, or a combination of both. My guess is the A7 is having yield problems. TSMC is notorious for this, and NVidia and ATI which both used TSMC used to have to frequently respin their silicon when they started hitting +1billion trannies.  The more trannies and die area, the higher the probability of defects. 

Thus, the A7 may in fact be costing Apple delays in parts and margins, because the more bad chips that come off of a wafer, the worse the margins. When most of the industry goes 64-bit in 2014, no one's going to care that Apple was first, just like no one cared who had the first dual core, quad core, or octa-core. Consumers don't care, only fanboys do, so they can engage in continuous penis measuring contests.

The iPhone 5S confers no benefit in battery life. Imagine if instead of doubling the number of transistors, Apple had instead, used the new semiconductor process to end up with a fall smaller SoC, it would drain less power, and be cheaper, and battery life would be greater. The question needs to be asked, does the iPhone already perform well enough? Does it really need 2x more CPU? Will consumers really notice that, or maybe they'll notice 20 hr battery life instead of 10? It's like having the ability to design a car with 2x the HP or 2x the gas mileage.  Increasing the power isn't always  the best win, as we learned from the desktop, eventually there are marginal returns.

(I'm guessing I'll be banned for writing an article that speaks positively of Android and semi-critical of Apple, as it seems you can get banned by these forums for merely stating the facts, while other people spew downright nasty ad hominems and nothing ever seems to happen, as long as you tow the Apple party line, it seems criticizing Apple is too hurtful)

yeah sure, Android coulda, shoulda, woulda. plus some pure speculation and penis trash talk.

why, you'll fit right in!
post #246 of 366
Quote:
Originally Posted by Dunks View Post
 

... It really does show you how tech journalism has devolved into regurgitating press releases.

 

You really didn't need the word "tech" in that sentence.

post #247 of 366

Saying that there aren't really any apps on iOS that take advantage of 64-bit is missing the point really. The hardware has to be there for it to be taken advantage of. All of Apple's iOS7 apps on the 5S will be 64-bit but these are existing applications. I'm sure it won't be long before Apple are creating apps that will do things previously not possible, or at least useable in 32-bit form.

 

Apple, as usual, are laying down the groundwork for what's coming. As Tim Cook said on Tuesday, there is nothing like iWork for iOS on Android and I expect that Apple are putting the finishing touches to an app that will only exist on 64-bit iOS. It will help drive sales of the 5S of course, and probably the next iPad which is also seems likely to be 64-bit. They will want a software and hardware synthesis that Samsung and the others really can't copy, at least for some time.

post #248 of 366
Quote:
Originally Posted by KiltedGreen View Post
 

Saying that there aren't really any apps on iOS that take advantage of 64-bit is missing the point really. The hardware has to be there for it to be taken advantage of. All of Apple's iOS7 apps on the 5S will be 64-bit but these are existing applications. I'm sure it won't be long before Apple are creating apps that will do things previously not possible, or at least useable in 32-bit form.

 

Apple, as usual, are laying down the groundwork for what's coming. As Tim Cook said on Tuesday, there is nothing like iWork for iOS on Android and I expect that Apple are putting the finishing touches to an app that will only exist on 64-bit iOS. It will help drive sales of the 5S of course, and probably the next iPad which is also seems likely to be 64-bit. They will want a software and hardware synthesis that Samsung and the others really can't copy, at least for some time.

 

 

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. The iPhone "won" because it won over consumers, while Blackberry and others thought creating devices for Enterprise users was key.  I don't think enterprise software really strengthens the case for most people. Are we now saying the "5s" is for guys who carry briefcases, and the 5c is for everyone else? Seems weird.

 

Leveraging 64-bit performance requires crafting software to leverage 64-bit math. If you're got a game, and you've got features, like enhanced physics engine or particle effects on 64-bit iOS, but not on 32-bit, then you've fragmented the market.  Fragmentation-by-performance increases cost for developers. Thus, I don't see 64-bit being that usable until a large number of 5s and 64-bit iPads are sold, enough to justify the design of killer apps for it.

 

But if you look at how 64-bit played out on the desktop, 64-bit never really mattered much in terms of "doing stuff that couldn't be done before". Most performance boosts came more from SIMD-extensions, not 64-bit scalars or MMX.

post #249 of 366
Quote:
Originally Posted by Alfiejr View Post


yeah sure, Android coulda, shoulda, woulda. plus some pure speculation and penis trash talk.

why, you'll fit right in!

 

It's not really penis trash talk to point out that people have been writing Java programs on 64-bit architectures for a long time and that, as applied to mobile, the switch over won't be difficult for non-native apps, it's just basic facts, and the "analyst" being quoted about how Android has to wait until Oracle upgrades Java to 64-bit or some such is basically clueless.

 

The biggest issue with 32-bit to 64-bit on Android, and there will be issues, is apps that use the NDK -- stuff written in C code and combined to ARM directly, and device drivers. Google is moving towards LLVM bitcode based solutions for this as Android will have to content with Intel Bay Trail oriented devices soon.  My  guess is, there's no rush, with 1 billion devices out there, developers really aren't going to care if even 1% of them are 64-bit at this point.

post #250 of 366
Quote:
Originally Posted by bitbyter View Post

... when they started hitting +1billion trannies.  The more trannies and die area, the higher the probability of defects. 

I so took this the wrong way.
post #251 of 366
This is a great article and brings up very interesting points. If Apple sell a few hundred million A7 powered devices that's nice revenue for TSMC and less of course for Samsung. This has to be an Apple objective.

How will we know if this is a fact?
post #252 of 366
Quote:
Originally Posted by KiltedGreen View Post
 

Saying that there aren't really any apps on iOS that take advantage of 64-bit is missing the point really. The hardware has to be there for it to be taken advantage of. All of Apple's iOS7 apps on the 5S will be 64-bit but these are existing applications. I'm sure it won't be long before Apple are creating apps that will do things previously not possible, or at least useable in 32-bit form.

 

Apple, as usual, are laying down the groundwork for what's coming. As Tim Cook said on Tuesday, there is nothing like iWork for iOS on Android and I expect that Apple are putting the finishing touches to an app that will only exist on 64-bit iOS. It will help drive sales of the 5S of course, and probably the next iPad which is also seems likely to be 64-bit. They will want a software and hardware synthesis that Samsung and the others really can't copy, at least for some time.

 

First, all of the shipped apps by Apple for iOS7 are supposed to be 64 bit.  But the real beneficiary early on for 64 bit performance is probably the camera app and the related logic in the A7 chip for the image processor.  I'm still carrying a 3 year old iPhone 4 (soon to be upgraded to the 5s) and I've seen the cameras for my mother's 4s and my wife's 5.  Both are much better than mine but the burst mode stuff for the 5s camera that is looking at every image at 10 fps, evaluating every one on six major criteria factors and presenting the best picture?  Really?  You don't think that 64 bittiness isn't playing a role here with all of that data having to be slung around and evaluated in real time?

 

As for Android going 64 bit, it is true that the virtualization that the platform already features will help.  Recently I had a large enterprise customer who was having a lot of Java related server problems and we came to discover that their enterprise production system was running on the ragged edge of memory for what the 32-bit JVM could do.  A move to the 64 bit version solved the problem, without a change to the production code.  Of course, running in bytecode is never going to be as fast as running natively, which is why Android phones frequently clock their processors faster than what Apple does with the A-series...they just have to for proper performance.

 

But I think the real problem for Android going 64 bit will again be the vendors.  It's one thing to have Android/Linux compile properly to a 64 bit version...it's another thing to have drivers for all the interfaces.  In the past, device manufacturers have had a hard enough time producing recent versions of Android to run on year old phones...most of the time they don't even bother.  The first 64 bit Android phones will be Nexus phones from Google...that much is certain.  But I wouldn't be surprised to see 64 bit hardware running 32 bit Android builds a year from now. 

post #253 of 366

DED got the story mostly correct. I don't need to provide extra links to verify my claims. DED already has them in his editorial. Moreover, all you really need to know to realize my claims are true is that Apple innovates its hardware and software together and manages its supply-chain wisely.

post #254 of 366
Quote:
Originally Posted by UrbanVoyeur View Post

This article is full of useful information and good reporting BUT you badly need and editor.

 

if you're going to criticize someone's editing, make sure you look in the mirror before you post. I'm only being a spelling fascist because the OP was whining about editing, using a really bad edit. 

 

I thought this article was well written and informative. This kind of substantive reporting is why I enjoy AI so much. I've pretty much stopped reading the other 'Apple press' - AI has really become the 'paper of record' for Apple reporting.

 

DED sometimes goes over the top with his pro-Apple cheerleading hyperbole, but this was an outstanding article.

 

It's just a matter of time before Daniel is offered a tech writer position at the NYT or elsewhere. (Daniel, PLEASE don't go to work for Wired - ugh! They're the National Enquirer of tech news).

 

For consideration as Daniel's next place of business, I would suggest the Amazon Times (er) Washington Post - there's been some excellent reporting coming out of the WP since Bezos (who I loathe) bought the paper.

post #255 of 366
Quote:
Originally Posted by bitbyter View Post
 

 

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. 

 

Attention USS Enterprise, Apple's firing photon torpedos across your bow. The iWork suite probably contributes little to Apple's expenses (certainly less than marketing), so when they start giving it away on their devices and the web, it will become a de facto standard in its own right.

 

Remember BYOD? Get ready for BYOA - bring your own apps / access. "Collaboration and backoffice"? As tablets replace laptops, the mobile space will be where people collaborate.

 

I agree that Pages, Numbers et al do not have the heft of Word and Excel . . . yet. Also, Apple's execution of mobile collaboration sucks today.

 

However, my wife is a grad student and HATES HATES HATES MS Word - and she uses it on the Mac.

 

Once she figured out how to footnote in Pages, she left the MBP at home and now takes the iPad to class.

 

64-bit software is going to allow a lot of new standards to be defined in the mobile arena. After Apple gets basic 'officelike' functionality working well in iOS and OS X, collaboration will be cleaned up, and the USS Enterprise will change course.

 

Not to mention that the real money and growth is in automating the millions of small businesses who keep word and excel docs on the "Y" drive to run their business. That paradigm is very 20th century and fading fast.

post #256 of 366
Quote:
Originally Posted by Stevel View Post
 

 

Yes this is what I'm talking about. I have to BUMP my phone because Apple does not have NFC. Samsung has had Wifi Direct since the Galaxy S2, and it is amazing. Why can't Apple do such a thing. File transfers are incredibly fast. Please help me make Apple better so we no longer have to download an App and ridiculously Bump our expensive iPhones. These phone are like jewels, we should not be forced to treat them this way just to transfer files and use up data. Wifi Direct is extremely easy, no need to bump anything, and it uses absolutely no data. Maybe you have some suggestions on how we can get Apple to implement this. I'm open to anything to help the iPhone get better and better to be the best iPhone ever. 

NFC is going to be looked at as gimmicky at best and Apple realized this long ago. http://gigaom.com/2013/09/10/with-ibeacon-apple-is-going-to-dump-on-nfc-and-embrace-the-internet-of-things/

post #257 of 366
@bitbyter the difference is Apple knows how to marry its new tech with the software/hardware while Android just crosses new tech off a check list.
post #258 of 366
Quote:

Originally Posted by vaporland View Post

...

 

64-bit software is going to allow a lot of new standards to be defined in the mobile arena. After Apple gets basic 'officelike' functionality working well in iOS and OS X, collaboration will be cleaned up, and the USS Enterprise will change course.

 

Not to mention that the real money and growth is in automating the millions of small businesses who keep word and excel docs on the "Y" drive to run their business. That paradigm is very 20th century and fading fast.

 

And at $300 or so a pop for Office, small business is just looking to get it replaced.  Big corporations will start looking to in order to shed the site license fees. 

post #259 of 366
Quote:
Originally Posted by bitbyter View Post
 

Java has always been 64-bit (long data types), and the Java VM has supported 64-bit addressing for years due to Java's use in the enterprise. Dalvik adheres to this spec and supports 64-bit data types and addresses. For application developers on Android, you won't even need to recompile software if it uses no native code, you'll get 64-bit use automatically once Dalvik is deployed at 64-bit.

 

I'm not sure Dalvik needs to be 64-bit. Android uses a separate Dalvik VM instance for each app, and it's unlikely an individual app will need more than 4 GB of memory.

 

For x86, I'd think Google would use the new x32 ABI. That has the architectural improvements of x64 (more registers, faster syscalls, faster dynamic linking, etc), without the pointer bloat.

 

As for ARM, I agree -- drivers will be stumbling block.

post #260 of 366
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.
post #261 of 366
Quote:
Originally Posted by dasanman69 View Post


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.

post #262 of 366
Quote:
Originally Posted by daywalker View Post
 

 

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.

post #263 of 366
Quote:
Originally Posted by masquisieras View Post

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?
How to enter the Apple logo  on iOS:
/Settings/Keyboard/Shortcut and paste in  which you copied from an email draft or a note. Screendump
Reply
How to enter the Apple logo  on iOS:
/Settings/Keyboard/Shortcut and paste in  which you copied from an email draft or a note. Screendump
Reply
post #264 of 366
Quote:
Originally Posted by PhilBoogie View Post


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 :)

post #265 of 366
Quote:
Originally Posted by masquisieras View Post
 

 

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

post #266 of 366
Quote:
Originally Posted by daywalker View Post
 

 

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

post #267 of 366
Quote:
Originally Posted by masquisieras View Post

Quote:
Originally Posted by PhilBoogie View Post

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 1smile.gif

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...
How to enter the Apple logo  on iOS:
/Settings/Keyboard/Shortcut and paste in  which you copied from an email draft or a note. Screendump
Reply
How to enter the Apple logo  on iOS:
/Settings/Keyboard/Shortcut and paste in  which you copied from an email draft or a note. Screendump
Reply
post #268 of 366

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.


Edited by Alfiejr - 9/16/13 at 1:01pm
post #269 of 366
Quote:
Originally Posted by Mechanic View Post
 

 

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. 

post #270 of 366

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.

 

From AnandTech comments (my emphasis):

Quote:
  • Nice catch. Stunning that the CCI shipped.REPLY
     
  • 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.REPLY
     
  • chizow - 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.
  • REPLY
     
  • 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.:

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 still isn't shipping. And anyone who owns an existing Exynos Octa-containing device basically got screwed by Samsung.

 

 

 

 

 

post #271 of 366
Quote:
Originally Posted by ksec View Post
 

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?


Edited by tooltalk - 9/17/13 at 7:51am
post #272 of 366
Quote:
Originally Posted by tooltalk View Post
 

So what exactly is so "disastrous" about Exynos again?

 

Clue: read comment directly above yours.

post #273 of 366
Quote:
Originally Posted by Tallest Skil View Post
 

 

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%3A+Liliputing+%28Liliputing%29

 

You really think they can design a 64 bit ARM processor from scratch in 6 weeks? Get serious...

post #274 of 366
Quote:
Originally Posted by kevliu1980 View Post

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.
post #275 of 366
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.
post #276 of 366
Quote:
Originally Posted by ruel24 View Post
 

http://liliputing.com/2013/09/android-ready-64-bit-processing.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Liliputing+%28Liliputing%29

 

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.

"Apple should pull the plug on the iPhone."

John C. Dvorak, 2007
Reply

"Apple should pull the plug on the iPhone."

John C. Dvorak, 2007
Reply
post #277 of 366
Quote:
Originally Posted by ruel24 View Post

http://liliputing.com/2013/09/android-ready-64-bit-processing.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Liliputing+%28Liliputing%29

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.
Better than my Bose, better than my Skullcandy's, listening to Mozart through my LeBron James limited edition PowerBeats by Dre is almost as good as my Sennheisers.
Reply
Better than my Bose, better than my Skullcandy's, listening to Mozart through my LeBron James limited edition PowerBeats by Dre is almost as good as my Sennheisers.
Reply
post #278 of 366
Quote:
Originally Posted by bitbyter View Post
 

 

 

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.

post #279 of 366
Originally Posted by bitbyter View Post
[entire post]

 

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 View Post

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”.

Originally Posted by Slurpy

There's just a TINY chance that Apple will also be able to figure out payments. Oh wait, they did already… …and you’re already f*ed.

 

Reply

Originally Posted by Slurpy

There's just a TINY chance that Apple will also be able to figure out payments. Oh wait, they did already… …and you’re already f*ed.

 

Reply
post #280 of 366
Quote:
Originally Posted by KiltedGreen View Post
 

When MS Office is available on Android or a Windows phone then I suppose there may be some competition!

 

Office 365 is available on Android, iOS and I'd presume Windows phone.

New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: iPhone
  • After its disastrous Exynos 5 Octa, Samsung may have lost Apple's A7 contract to TSMC
AppleInsider › Forums › Mobile › iPhone › After its disastrous Exynos 5 Octa, Samsung may have lost Apple's A7 contract to TSMC