Samsung Launches the Galaxy Note 4 LTE-A

56 Comments

View All Comments

• name99 - Monday, December 29, 2014 - link

  This is way too strong a claim.
  The case on ongoing demand for high CPU is a limited one, but the case of on-going interest has to do with the burstiness of CPU demand. Over a period of, say, 10 seconds, the average CPU usage may be below 10% even during actual interactions (eg browsing the web). But there are periods during those 10 seconds where multiple CPU intensive things can occur simultaneously. Eg scrolling upward will require UI interaction, plus perhaps some image decompression of pictures that were downloaded earlier but not yet displayed, plus some network/OS interaction that pulls in content even further down the page.
  
  The value of multiple CPUs is primarily in handling such simultaneous peaks. It is unquestionable that two CPUs are valuable for this purpose under almost all circumstances --- the iPhone 4S felt a lot snappier than the iPhone 4, where the only difference in the CPUs was two vs one. Three CPUs is a trickier call. My iPad Air 2 feels crazy snappy --- but that's compared to my older retina iPad 3; I never had an iPad Air so I can't really say how much different the third core makes wrt snappiness. We have basically NO metric/benchmarks that measure snappiness, so reviews are no help.
  Apple tend to be pretty sensible about when they add CPU, so I'm guessing they do have internal tests that show substantial value for three cores.
  
  What about A57+A53? The problem with saying "lotsa slow cores [2+4] is a better match to real world usage" is that, while it is TRUE, it is also not ACTIONABLE. For most purposes, you don't know until after the fact whether a given work item needed the performance of a fast core or could have been handled in time with a slow core.
  There are a few cases you do know. Work scheduled in the background is obvious. Much network work and interrupt handling can probably happen on the slower core. But tasks submitted by the main app and UI work have to be handled by a fast core to be safe.
  Configs with a few fast cores and lots of slow cores are a good match for servers, where the workloads are very predictable and your OS can be told (or can even learn automatically if it's outfitted with some machine intelligence code) which requests to send to slow vs fast cores. This is a much harder problem on phones, and you don't want your phone to get a reputation as "yeah, it usually seems fast, but every so often it seems to just take twice as long to respond to a button press or a scroll --- drives me crazy!"
  
  In theory Win8 would seem the phone OS currently best suited to taking advantage of these many core CPUs. They have, in the latest versions of C#, a much richer and easier to use framework for async calls than either OSX or Android, and they have been extremely aggressive about ensuring that every call in Metro that could be performed async is given only an async API, so that sync is not even an option. [The ideas that make this work will be part of C++17, which means, among other things, that those capabilities that are not yet in LLVM will soon be there, which means in turn, IMHO, that Apple will be adding the same sort of facilities to Swift --- we may even heard about them at WWDC2015, but Apple still then has to retrofit these capabilities to their APIs. Java seems less advanced than C# in this style of programming, and I don't know that Google can move as fast as Apple given the Oracle Java involvement...]
  So in principle WP8 could fly on these octacore CPUs (as could Windows RT) but WTF can understand MS' marketing philosophy? They seem to have given up utterly on Win RT so their only tablet story is x86 based, and they seem unwilling [or scared] to compete in phones at the high end, so they don't run their OS on these cores even though (theoretically at least) they're a perfect match. [Which does make you wonder if there is some horrible design flaw inside Metro which renders this theory moot and makes it scale very baldy to more than two or so cores. I guess we'll see if Win10 gets shipped on more aggressive HW.]

• Conficio - Tuesday, December 30, 2014 - link

  I like your argument about the average CPU load over (relatively) long periods of time being meaningless.
  
  While, I have little practice in mobile programming or Windows/iOS/OSX programming for that matter. I thought Apple has taken care of the multi thread paradigm long time ago (2010 for iOS 4 - http://www.anandtech.com/show/3779/apples-ios-4-ex... , http://arstechnica.com/apple/2009/08/mac-os-x-10-6... ) with the Grand Central scheduling theme. This is past tense, not C++17 future like WP8.

• name99 - Tuesday, December 30, 2014 - link

  Parallel programming done easily requires a VERY LARGE set of primitives.
  Apple offers some of the basic elements. GCD offers thread pools (but a rather clunky syntax for specifying how to use them if you want more than the default). Blocks offer the equivalent of C++11 or C# lambdas. But that is all right now.
  Apple does NOT (that is, does not offer in Swift or ObjectiveC, of course they track C++) for example, offer
  - atomics (C++11)
  - futures (C++11)
  - aggregation of futures (any or all) (C++17)
  - .then (C++17)
  - parallel for and similar constructs (probably C++17, but I don't know for definite)
  
  C# has a pretty incredible resource in the async/actor-based programming they offer, not to mention, as I said, that they have this woven throughout the Metro API.
  
  The difference between what Apple offers today and what C# offers today is the difference between a language that offers malloc and a managed language. I'm an Apple fan, but let's not let fandom turn us stupid (which is the history of every fandom --- I remember when idiots were arguing in the 90s that co-operative multi-tasking was superior to pre-emption, and that a single address space was superior to protected VM). MS is far ahead of what Apple offers today as regards language, API, developer tools, and probably performance.
  
  It doesn't have to stay that way --- Apple has done an awesome job of learning the best ideas from a range of modern languages to create the Swift we have seen so far, and I expect they will do the same when it comes to adding parallelism. (For example, in addition to the actor-like programming that Metro/C# does so well, you'd like to see fine-grained heterogeneous parallel programming, ie OpenCL/CUDA type programming, added to the language in a way that fits the syntax and is very natural. MS offers C++AMP to deal with this, and AMP seems likely to be part of C++17; but AMP is as ugly and clumsy to use as everything is in C++ these days, and isn't beautifully integrated into C# syntax.)
  But dreaming about Swift next WWDC is the future, not today...

• sonicmerlin - Thursday, January 1, 2015 - link

  Hah I went from an iPad 3 to an Air 2 as well. It's ridiculous the difference in speed, weight, screen quality and brightness, battery life, etc. 2 GB of RAM is also a godsend.
  
  Also the rest of your post was very interesting. Thanks.

• Vegator - Monday, December 29, 2014 - link

  As an aside, the Cortex-A53 based SoCs such as MT6732 and MT6752 are really a step up from current cost-sensitive SoCs like Snapdragon 400. Not only do they have great multi-core performance, single-core integer performance has also doubled (1.2 GHz Cortex-A7 Snapdragon 400 vs. 1.7 GHz Cortex-A53 in MT6752), floating point somewhat less. This of course makes a tangible difference, even without considering multi-core.
  
  Memory performance and efficiency is also greatly increased in chips like MT6752 (although not yet in earlier Qualcomm Cortex-A53 SoCs like the low-end Snapdragon 410), meaning they get a lot more performance out of an economical 32-bit memory subsystem than existing solutions while keeping cost down.

• name99 - Monday, December 29, 2014 - link

  Presumably the A57 on the 810 is an actual working A57 (unlike that bizarre pathetic little "A57" on the Exynos that seems to be incapable of actually operating 64-bit code). But who knows?
  
  I don't think Samsung ever gave a coherent explanation of why their Exynos A57 was so crippled --- presumably it was NOT a function of the core design, which suggests it was a function of either the peripherals or Samsung firmware. You'd like to think those issues have been corrected the past three months, but if the selling point for this device is "look, three x aggregation --- in the non-existent markets that offer this" rather than "look, 64-bit" that suggests Samsung still haven't got their act together.
  
  So, bottom line, this thing probably is NOT going to offer any sort of realistic benchmarks of how A57 compares with A8.
  [And, if I'm right about Samsung's issues, who knows? Maybe Apple will have launched the large-screen iPad Pro with A9 in early Q2 before someone is offering an actually functioning 64-bit A57 system?]

• mfmx - Thursday, January 1, 2015 - link

  And you know all the details about Exynos 5433 from where? Gossip and rumors on Anandtech?
  
  FYI, Note 4 is marketed in Asia as a 64-bit device.

• jettto - Monday, December 29, 2014 - link

  Nothing interesting. Knowing K1 crushes Snapdragon with only a dual core and Apple's own cpu with triple crushes everything.... Snapdragon is completely ridicules

• tipoo - Monday, December 29, 2014 - link

  You also have to look at the power draw of the Denver version of the Nvidia K1. It's not suitable for phones. Maybe when they jump ship to 16nm.

• Morawka - Monday, December 29, 2014 - link

  isn't the 810 using a cookie cutter configuration from ARM itself A53/57? basically qualcom adds their modem and power management IP's and call it a day.
  
  Since this is a cookie cutter build, time to market should be greatly reduced, but it seems that is not the case. Nevermind a fully custom core like apple's a7 and a8