Google Pixel C: "Quad Core Tegra X1"

[Entropy]

Yes they'll do it (in terms of basic principle of low-power + high-perf clusters).

Keep in mind this isn't a design decision that you simply switch to at the snap of a finger, ARM has quite the lead here. The Zenfone 2 doesn't really have what one could consider good battery life and Intel is otherwise quite less aggressive than other vendors in the space. Apple is the only outlier here but in my opinion that's mainly due to just having a vastly different and more efficient OS. I'm sure if I were to lay out the perf/W curves it'd end quite up below current ARM cores.

To be fair though, the issue with big.LITTLE as it looks today isn't in the performane/power curves. The issue lies in what the actual use cases are that makes such a setup worthwhile overall. Bursty loads require the higher power cores. Non-bursty loads such as games typically require higher power cores (albeit not necessarily at their highest clocks as nicely demonstrated by your article). At the other end of the spectrum, idling, waiting for user input, doesn't require a quad cluster, a single low power core or specific low power core state suffices.
So while you can make a case for big.LITTLE if you have a need for a continously sliding scale of multi core performance, I just can't see that being a big concern in real life usage.

 

[Ailuros]

No one has been able to show that global task scheduling is useful. There are no benchmarks illustrating it saves power or improved performance.

Marketing.

Then why did NV implement a quad LITTLE cluster in the first place if it's all marketing? You realize that one exception is hardly good enough to pose for any rule when the widest majority actually uses GTS in a big.LITTLE config and yes it can save power if done right.

To be fair though, the issue with big.LITTLE as it looks today isn't in the performane/power curves. The issue lies in what the actual use cases are that makes such a setup worthwhile overall. Bursty loads require the higher power cores. Non-bursty loads such as games typically require higher power cores (albeit not necessarily at their highest clocks as nicely demonstrated by your article). At the other end of the spectrum, idling, waiting for user input, doesn't require a quad cluster, a single low power core or specific low power core state suffices.
So while you can make a case for big.LITTLE if you have a need for a continously sliding scale of multi core performance, I just can't see that being a big concern in real life usage.

Considering that the ballpark in power consumption and die area between A53 & A57 vs. A7 & A15 cores is way smaller it can become a moot point but up to a point. You cannot have varying frequencies within each cluster and you don't always have just single threaded cases.

If I have one very demanding task for which I'd need to run one A57 (out of the 4 available) at say 2.0GHz and one very simple task at the same time which under normal conditions you could run it on a A53 at say 400MHz; lack of availability for the latter wouldn't I be forced to complete in theory both tasks on two different cores in parallel at 2.0GHz or am I missing here something?

Obviously for the devices NV is integrating up to now the X1 power consumption isn't as much of an issue, but that doesn't change the above.

 

[Lazy8s]

big.LITTLE's acceptance within Android, by itself, doesn't say a lot more than it possibly being a better approach when an OS manages workloads like Android does.

Free of that, if iOS is indeed a "more efficient" or more ideal system of operation with respect to managing the workloads relevant to mobile computing, Apple's freedom to create a processing approach best suited to match that and then their choice to not adopt a big.LITTLE type scheme doesn't help big.LITTLE's case overall... but, with the lack of a big.LITTLE-like counter-example for iOS, it doesn't say a lot against it either.

The only thing that seems clear from Anandtech's great in-depth workload testing is that Android is able to make good use of the granularity provided by big.LITTLE, whether or not such a division of the overall system workload was optimal in the first place.

 

[Lazy8s]

And to add: even on Android, going with processing approaches different to big.LITTLE like with Intel's Atom and Qualcomm's Krait, results (performance and efficiency) can still be competitive with potentially less (or more... not enough data to know) overhead in the silicon design and costs.

 

[wishiknew]

Wonder if the 820 will have big.LITTLE or 810 was a one time thing due to the A57.

 

[RecessionCone]

Then why did NV implement a quad LITTLE cluster in the first place if it's all marketing? You realize that one exception is hardly good enough to pose for any rule when the widest majority actually uses GTS in a big.LITTLE config and yes it can save power if done right.

I didn't say the little cluster wasn't useful. I said GTS is a lot of complexity for essentially no measurable gain. No one has been able to show it is a good idea. Nebu's benchmarks show that it can be active in a few niche cases, but then again there are many active technologies that are bad ideas.

Every time people get on NV's case for lacking GTS, I have to ask where is the evidence that GTS is useful for anything. Haven't seen any yet.

 

[RecessionCone]

Oh god not this discussion again. When basically every ARM (and MIPS for that matter) vendor in the industry besides Apple is embracing bL maybe it's time to start to think that it's maybe not marketing?

http://anandtech.com/show/9518/the-mobile-cpu-corecount-debate/18
http://anandtech.com/show/9330/exynos-7420-deep-dive/6

If perfect use-cases like this one don't convince you then nothing will.
http://anandtech.com/show/9518/the-mobile-cpu-corecount-debate/16

The only reason Nvidia doesn't have it is because their interconnect just can't do it.

Sorry, your benchmarks don't prove GTS is useful. They show it might be active, but not that it is a good idea. They certainly don't show that a big+little implementation without GTS (like in X1) is disadvantaged in any real world scenario.

 

[Ailuros]

I didn't say the little cluster wasn't useful. I said GTS is a lot of complexity for essentially no measurable gain. No one has been able to show it is a good idea. Nebu's benchmarks show that it can be active in a few niche cases, but then again there are many active technologies that are bad ideas.

Then maybe you yourself should watch any big.LITTLE config capable of GTS in real time close up before jumping to conclusions. I personally would prefer to not have big.LITTLE configs and varying frequencies within quad cores for instance, but that's besides the point.

In a balanced implementation for a 4+4 config GTS can have benefits, especially since core utilization is not really limited to 1, 2 or just 4 cores in total as sadly many still believe. Just loading a heavy page while browsing is usually at least 5-6 cores at varying persentages with one big core reaching a quite high single core persentage.

Every time people get on NV's case for lacking GTS, I have to ask where is the evidence that GTS is useful for anything. Haven't seen any yet.

The ULP mobile doesn't spin around NV; in fact they are still (outside of markets like automotive) pretty much irrelevant for it. Either we can keep a pure technical perspective on the matter, because any possible emotional stuff should leave folks here in the cold. Fact is that they've switched off the A53 cluster in X1 because probably for the markets they're addressing power consumption isn't that much of a big deal; that still doesn't invalidate whatever else implementation the rest of the Android world uses and to that at its majority, nor is it useless because a minority report doesn't use it.

Anandtech's writeup deals with core utilization in a big.LITTLE config within a smartphone.

 

[Nebuchadnezzar]

I said GTS is a lot of complexity for essentially no measurable gain. No one has been able to show it is a good idea.

That you choose to ignore the data is not a problem of of the technology. That one example isn't just a niche situation it's just one where it's blatantly visible. The perf/W curves are there. The fact that running 3 threads on a CPU at twice the efficiency is better than alongside the high perf cluster should be visible to anybody.

 

[Entropy]

That you choose to ignore the data is not a problem of of the technology. That one example isn't just a niche situation it's just one where it's blatantly visible. The perf/W curves are there. The fact that running 3 threads on a CPU at twice the efficiency is better than alongside the high perf cluster should be visible to anybody.

Yes it is. And a nice article overall.
But there are a number of critical questions left to answer that aren't trivial, nor necessarily possible to answer at all. For instance:
* How large a portion of overall use does such a case represent?
* In these scenarios, what is the overall power draw of the device? If the CPU draws relatively little, won't its power draw be swamped by screen+BT/WiFi/4G?
* Even if arguably useful, is it MORE useful than alternative uses of die area? For instance, should Apple have gone with a cluster of four weak cores rather than the IPC enhancing measures (such as increased L2) they actually went for in the A9? Would it be better for the typical user if they added a weak four core cluster to the A10, or a third strong core, that can assisst in the heavier use cases?

Being able to make a case for an engineering approach, doesn't mean that a stronger case can't be made for another. While I don't dismiss that there can be benefits to big.LITTLE designs, I am definitely unconvinced that it is necessarily the best use of resources possible in these devices.

 

[Ailuros]

Yes it is. And a nice article overall.
But there are a number of critical questions left to answer that aren't trivial, nor necessarily possible to answer at all. For instance:
* How large a portion of overall use does such a case represent?
* In these scenarios, what is the overall power draw of the device? If the CPU draws relatively little, won't its power draw be swamped by screen+BT/WiFi/4G?
* Even if arguably useful, is it MORE useful than alternative uses of die area? For instance, should Apple have gone with a cluster of four weak cores rather than the IPC enhancing measures (such as increased L2) they actually went for in the A9? Would it be better for the typical user if they added a weak four core cluster to the A10, or a third strong core, that can assisst in the heavier use cases?

I'm a layman so any real time on a 4*A15+4*A7 config based observations might be interpreted wrong, so cut me some slack for that:

* All the time and for the majority of applications. Manhattan and T-Rex are extremely GPU bound (as they should be as a GPU benchmark) and for most of the time use just one A7 core at not even at full tilt. It's my understanding that usually in such configs the LITTLE cluster has priority in utilization and only when the going gets tough the big cluster chimes in. As I said before loading a heavy page while browsing is typically ~3 LITTLE cores and up to 2 big cores with one running up to its peak for a very small fraction of time. An interesting twist is that I can if I want switch priority between the clusters and have the A15 clusters get utilized first. It's not that the system doesn't use the LITTLE cluster at all, yet giving alone to the big cluster cores priority costs around 30% less battery life. Needless to say that the system gets somewhat more responsive but the cost is too high.

* Considering the above I have on that 4+4 config with the majority of work falling on the A7 cluster with the A15 cluster kicking in quite rarely and mostly when you really need very high single threaded performance about 8 hours battery life while browsing and also considering the above tidbit where switching priority between clusters gets me down to about 5 hours, imagine how it would look like if I had ONLY the A15 cluster. Note though that the case example here is a best case scenario, since the power differences between A15 and A7 cores are quite a bit bigger than A57 vs. A53.

* IMHO and I'd love to stand corrected but ARM, IMG or whoever else sells CPU IP has to give to all its partners equal chances for integration. Having varying frequencies in a quad cluster might be the best solution around, however an ideal implementation presupposes also tight adjustments with the manufacturing processes. A luxury low cost SoC manufacturers won't have. The best alternative solution for that headache is big.LITTLE; "all" a manufacturer needs to do for it is to find the best possible power/thread management for it. Remember that for Kepler and somewhat Maxwell that bit of extra die area for dedicated FP64 SPs didn't kill any GPU chip transistor budget and it does in fact save power. Pascal and onwards might not be on that same track because it has other variables to handle, but the former is for the former two true. For the record's sake having asynchronous frequencies for a quad core CPU is neither cheap (see above process adjustments) nor does it come with zero added transistors either.

Being able to make a case for an engineering approach, doesn't mean that a stronger case can't be made for another. While I don't dismiss that there can be benefits to big.LITTLE designs, I am definitely unconvinced that it is necessarily the best use of resources possible in these devices.

Assume that for the last point I am not standing on the wrong foot, big.LITTLE is a necessary evil for the CPU IP world. From that point and on any SoC manufacturer can screw up with the implementation whether it's a big.LITTLE or AMP config. For NV's case and X1 specifically I stand to my opinion that for the devices they use it for they do not really need the A53 cluster. If it would had made it into an ultra thin tablet for example I'm confident that they would have both clusters operative.

 

[swaaye]

Anandtech has reviewed the Pixel C and it doesn't sound good. Yet another buggy and disappointing Android release, but also some hardware design problems. CPU looks ok, GPU looks great, storage performance is ugly. Etc.
http://www.anandtech.com/show/9972/the-google-pixel-c-review

I've spent a few weeks using an Android netbook and these guys mirrored my thoughts on the OS for that sort of usage. Keep it away from me.

 

[swaaye]

Apparently this hardware was designed for ChromeOS but they put Android on it the end. It has a ChromeOS embedded controller that causes complications for Android development.

http://forum.xda-developers.com/pixel-c/general/pixel-c-rant-developer-perspective-t3301632
https://www.chromium.org/chromium-os/ec-development
http://arstechnica.com/gadgets/2015...ad-from-chrome-os-concept-to-android-adoptee/

 

[Deleted member 13524]

It always sounded weird how the Pixel C was marketed as a productivity device but it didn't come with google's productivity OS.

 

[Silent_Buddha]

I get the feeling that Google wants to stop development of Chrome OS and just focus and expand Android OS.

Regards,
SB

 

[tuna]

Chrome OS is really popular in the education market. That does not make a lot of money though (in my guesstimate).

 

[zed]

Chrome OS is really popular in the education market. That does not make a lot of money though (in my guesstimate).

I can't see education specific but its desktop share is only
0.51% of marketshare worldwide
1.5% north america (though thats higher than linux)

In saying that Im thinking of getting my GF a chrome laptop next, it literally (& I mean literally) does everything she wants from a PC

 

[swaaye]

In saying that Im thinking of getting my GF a chrome laptop next, it literally (& I mean literally) does everything she wants from a PC

Probably true for the majority of people. Android and IOS do enough for many people too.

Chrome has to be better than those when you want a keyboard and mouse though. I despise Android in that situation.

 

[swaaye]

NotebookCheck has a more positive, very thorough review of Pixel C.
http://www.notebookcheck.net/Google-Pixel-C-Tablet-Review.158868.0.html

 

[Blazkowicz]

Is it a laptop, is it a tablet? Seems like a tablet after having a look at it.

It feels like a product that was made because it was possible to make it - a common pitfall : e.g. a lot of IoT stuff is being developed though nobody asked for it, a good > 90% of it will likely fail.

So, the Ipad Pro got made, which looks like good hardware but we don't really know what it's for. May end up as a tool for the CEO, CFO, CTO etc. to check mail. On the other side there is nvidia Shield : wow! but where are the games.
So, Pixel C is at the intersection of the markets for nvidia Shield and Ipad Pro

What was interesting is to learn about the 2560x1800 screen, i.e. it has sqrt(2) aspect ratio . That's innovative. I believe a 1280x900 smartphone thing would be worth a try.