New ARM CPU and GPU slides leaked (Updated with new source)

[Trixanity]

ARM slides detailing the future of their IP has been leaked.

ARM has long had a fairly slow release cadence but it seems they've picked up speed with them announcing A75, A55 and G72 (high performance CPU, high efficiency CPU and high performance GPU respectively. These will be successors to A72/A73, A53 and G71.

 

A53 has seen wide-spread use by multiple semi-conductor companies and has been employed in numerous designs. The A53 was actually announced in 2012, so as you can imagine it was long overdue for a successor. With up to 2x higher performance, 15% more efficient and being more configurable, the A55 will also be used in numerous designs from entry level to flagship as efficiency clusters.

Spoiler

 

The A75 will be a welcome replacement for the A72/A73. A73 was a good efficiency gain over A72 but also regressed in performance in some areas. It will offer 20% more performance than A73 with the same efficiency

Spoiler

 

 

The G71 marked a huge performance improvement in ARM's graphics endeavors with scalable designs that finally matched what Qualcomm's Adreno chips could offer where we saw Samsung implement an MP20 design in their Exynos 8895 that actually exceeded Qualcomm's Snapdragon 835 (which has their latest Adreno 540) in graphics performance. The G72 will continue this trend with 25% better efficiency and 20% better performance density.

Spoiler

 

Lastly, they'll also reveal more about their new DynamIQ cluster designs which is an improvement over conventional big.LITTLE (the use of multiple clusters of varying design or performance characteristics) which has been the paradigm in ARM designs and therefore the de facto standard in Android devices.

Spoiler

 

All this will be revealed at the ARM Tech Day on Monday the 29th.

 

Source: https://www.nextpowerup.com/news/36256/leaked-slides-detail-arms-new-cpu-and-gpu-designs/

 

--------------------------------------------------------------

UPDATE:

So ARM had its Tech Day and the embargo has been lifted.

This means Anandtech has done an analysis of what we can expect by dissecting the PR numbers.

It seems the performance of the new A55 cores are hitting a ceiling by remaining In-Order but the cost for going Out-of-Order in power consumption might be too great for now.

 

DynamIQ is a huge shift in how ARM does multicore processors. We've been used to a maximum of 4 cores per cluster and using 2 clusters with each cluster having the same cores. With DynamIQ things will change. It will provide the ultimate flexibility with clusters with up to 8 cores and you can now mix your cores however you want meaning a 7 x A55 and 1 x A75 is possible now, for example.

This change also improves L2 cache latency by 50% simply by moving the L2 cache closer to the cores.

Quote

With bL, CPUs inside a cluster had access to a shared L2 cache; however, DynamIQ compatible CPUs (currently limited to A75/A55) have private L2 caches that operate at the CPU core’s frequency. Moving the L2 closer to the core improves L2 cache latency by 50% or more. DynamIQ also adds another level of cache: The optional shared L3 cache lives inside the DSU and is 16-way set associative. Cache sizes are 1MB, 2MB, or 4MB, but may be omitted for certain applications like networking. The L3 cache is technically pseudo-exclusive, but ARM says it’s really closer to being fully-exclusive, with nearly all of the L3’s contents not appearing in the L2 and L1 caches. If the new L3 cache was inclusive, meaning that it contained a copy of a CPU’s L2, then its performance benefit would be largely mitigated and a lot of area and power would be wasted.

Anandtech's analysis, as always, is worth a read.

There is sadly not anything on the new G72 GPU though.

 

Source: http://www.anandtech.com/show/11441/dynamiq-and-arms-new-cpus-cortex-a75-a55

[Nicnac]

 hope apple is going to make an ARM device

[Misanthrope]

10 minutes ago, Sampsy said:

What a truly awful set of slides. 121% increase in performance -> Make the bar twice as long. 197% increase -> Make the bar 5x as long. 

At this point they probably feel like they need to post bullshit graphs to compete with the likes of AMD, Nvidia and Intel.

[tsk]

Looks very good, about time A53 got a replacement. Now to see if my Nexus 5 will survive long enough for my next phone to have an A75 based chip in it. 

[Doobeedoo]

Ok looks very good, the graphs though heh. 

DynamicIQ cluster design is very interesting, read about it before too. But big.LITTLE being the go to for smartphones is still interesting how it works in practice, event Apple lately with 2 big and 2 small cores. The design was always odd to me, in a way. Even having performance and efficiency cores I'd expect that having only one strong cores could do tasks even faster and be done with it. Guess activating such bigger cores even for some quicker execution than slower one wouldn't bring much efficiency than having another efficient cluster. 

Some snartphones have like 8 same cores which is odd and some have like couple of clusters having 10, 12 cores,  so weird. Some to come. 

I wonder will there be a core design that will be efficient even more depending the lighter task without the need for different core clusters for efficiency part. 

[yian88]

All i want is big.LITTLE type arhitecture on desktop, 4 big cores running 4-5ghz from amd and 4 smaller ones 2-3ghz or something, for a lot cheaper cpu-s if possible.

So many tech inovations on mobile and 0 on desktop cpu.

[79wjd]

3 minutes ago, yian88 said:

All i want is big.LITTLE type arhitecture on desktop, 4 big cores running 4-5ghz from amd and 4 smaller ones 2-3ghz or something, for a lot cheaper cpu-s if possible.

So many tech inovations on mobile and 0 on desktop cpu.

There probably wouldn't be enough power savings for bigLITTLE to make sense on laptops and certainly not on desktops.

[Trixanity]

14 minutes ago, Doobeedoo said:

Ok looks very good, the graphs though heh. 

DynamicIQ cluster design is very interesting, read about it before too. But big.LITTLE being the go to for smartphones is still interesting how it works in practice, event Apple lately with 2 big and 2 small cores. The design was always odd to me, in a way. Even having performance and efficiency cores I'd expect that having only one strong cores could do tasks even faster and be done with it. Guess activating such bigger cores even for some quicker execution than slower one wouldn't bring much efficiency than having another efficient cluster. 

Some snartphones have like 8 same cores which is odd and some have like couple of clusters having 10, 12 cores,  so weird. Some to come. 

I wonder will there be a core design that will be efficient even more depending the lighter task without the need for different core clusters for efficiency part. 

I'm not sure of Apple's direction but they seem a little behind in execution of the multi-cluster paradigm. They've started out like the rest of the 'gang' with two clusters sharing coherency but not being able to operate at the same time so it's either big or small cluster being active at a time. The rest have since moved to the clusters being less rigid and being able to activate cores at will. I wonder if Apple will move in the same direction on A11.

 

The SoCs using the same cores between clusters (eg 4 x A53 + 4 x 53) are not entirely the same. The core design is the same but they're usually clocked differently and probably have different cache configurations which adds up to the power and die area difference between clusters. I'm guessing that along with the different clock speeds they therefore also have different power states adding to the power savings. Otherwise I'd agree that it makes no sense. 

[randomhkkid]

1 hour ago, Trixanity said:

I'm not sure of Apple's direction but they seem a little behind in execution of the multi-cluster paradigm. They've started out like the rest of the 'gang' with two clusters sharing coherency but not being able to operate at the same time so it's either big or small cluster being active at a time. The rest have since moved to the clusters being less rigid and being able to activate cores at will. I wonder if Apple will move in the same direction on A11.

 

The SoCs using the same cores between clusters (eg 4 x A53 + 4 x 53) are not entirely the same. The core design is the same but they're usually clocked differently and probably have different cache configurations which adds up to the power and die area difference between clusters. I'm guessing that along with the different clock speeds they therefore also have different power states adding to the power savings. Otherwise I'd agree that it makes no sense. 

Apple bet on narrow and fast rather than wide and slow. This is why their single threaded performance is so much higher than any other mobile device, it''s helpful to think of it as Intel vs AMD, Apple went for few cores with high IPC whilst Android went lots of cores and lower IPC. This made it easier for many developers as multit-threading is difficult and helped the iOS ecosystem grow. Furthermore Apple pushed GPU acceleration pretty early on, helped by their insanely powerful GPUs. It's hard to say which will pan out long term but Apple's CPUs are undoubtedly industry leading for the meantime. 

[tsk]

2 hours ago, tsk said:

Looks very good, about time A53 got a replacement. Now to see if my Nexus 5 will survive long enough for my next phone to have an A75 based chip in it. 

I jinxed my self so f***ing hard, dropped my phone today and the screen shattered. 

 

Oh well, no A75 for me! 

[Trixanity]

2 hours ago, randomhkkid said:

Apple bet on narrow and fast rather than wide and slow. This is why their single threaded performance is so much higher than any other mobile device, it''s helpful to think of it as Intel vs AMD, Apple went for few cores with high IPC whilst Android went lots of cores and lower IPC. This made it easier for many developers as multit-threading is difficult and helped the iOS ecosystem grow. Furthermore Apple pushed GPU acceleration pretty early on, helped by their insanely powerful GPUs. It's hard to say which will pan out long term but Apple's CPUs are undoubtedly industry leading for the meantime. 

I didn't comment on the number of cores or the design of them. I commented on their cluster configuration. I don't think there is any advantage to operating with rigid clusters. In fact I think it's a disadvantage both in performance and power. Instead of having the flexibility to migrate threads between clusters seamlessly you have to schedule for when you switch cluster. I have a feeling Apple will go in the same direction as the rest of the industry have. I think it's a massive paradigm shift to take on in one go hence the rest of the industry started with the rigid model before dipping their toes with flexible core clusters. I can only imagine how different it is not only architecturally but also in how you write your kernel for it. It adds complexity.

 

From what I understand Android works quite well with the number of threads given to it (and Android 'helps' the developers with it). There are a lot of scenarios where single threaded is king but there is a point to the madness of throwing more cores at the problem; they don't just go 'moar cores' and then have half of them remain idle permanently.

1 hour ago, tsk said:

I jinxed my self so f***ing hard, dropped my phone today and the screen shattered. 

 

Oh well, no A75 for me! 

Funny you should say that. I just picked up a new phone today and put it on my bed while I fumbled with my old phone to get the SIM card out. As I was doing that, apparently the light movement on the bed caused my new phone to slip over the edge and land screen first on the floor. Luckily it appears to be unharmed but I had a small heart attack for a second.

[LAwLz]

If I am reading the stuff about the A55 correctly, then it's kind of disappointing. Sure the performance increase is nice, but what really matters for the A53 and A55 segment is efficiency, which is "only" 15% better. So that "double the performance" (which is just in a few scenarios) will certainly not be free as far as power goes. It will be nice to see higher performance in low-end phones though. It would be neat if the next Raspberry Pi used A55 (and Gigabit Ethernet, please).

 

 

5 hours ago, Doobeedoo said:

Even having performance and efficiency cores I'd expect that having only one strong cores could do tasks even faster and be done with it. Guess activating such bigger cores even for some quicker execution than slower one wouldn't bring much efficiency than having another efficient cluster. 

I am pretty sure it depends on the task. When you got a big job with a clear start and end to the task race to sleep works well. You just fire up the big cores, finish the stuff and then shut them down.

But for things like scrolling a menu you can't really constantly shut the cores down and fire them up just because the user decides to scroll once every 5 seconds. Nor can you keep the big cores active for trivial tasks like updating a message conversation in the background, or audio control when the screen is turned off. You know, things which are small enough that the LITTLE cluster can execute them very quickly too.

 

4 hours ago, Trixanity said:

They've started out like the rest of the 'gang' with two clusters sharing coherency but not being able to operate at the same time so it's either big or small cluster being active at a time.

Wow what? Does iOS really do cluster switching? You'd think that with all the experience Apple has on board they would have done big.LITTLE properly.

 

3 hours ago, randomhkkid said:

Apple bet on narrow and fast rather than wide and slow.

Apple actually bet on wide and slow. All of Apple's own architectures have been very wide, but clocked at low speeds.

[randomhkkid]

3 minutes ago, LAwLz said:

Apple actually bet on wide and slow. All of Apple's own architectures have been very wide, but clocked at low speeds.

I meant in terms of the number of cores rather than the architecture of the core itself. But yeah I guess I shouldn't have used that terminology specifically

[Doobeedoo]

34 minutes ago, LAwLz said:

I am pretty sure it depends on the task. When you got a big job with a clear start and end to the task race to sleep works well. You just fire up the big cores, finish the stuff and then shut them down.

But for things like scrolling a menu you can't really constantly shut the cores down and fire them up just because the user decides to scroll once every 5 seconds. Nor can you keep the big cores active for trivial tasks like updating a message conversation in the background, or audio control when the screen is turned off. You know, things which are small enough that the LITTLE cluster can execute them very quickly too.

Yeah true, though why for such trivial tasks there are many of those cores even. I get for Android it's very common 4+4 I can get performance cores going with quad core route though for easy and simple tasks why also have 4 efficient cores, no 1-2 hmm.

[Trixanity]

33 minutes ago, LAwLz said:

Wow what? Does iOS really do cluster switching? You'd think that with all the experience Apple has on board they would have done big.LITTLE properly.

I'm quite sure Anandtech said that in their A10 write-ups but I could be wrong. Since all the other players did the same in their first attempt I guess you want to slowly shift your designs to get rid of bugs and other problems in the implementation before you go all in.

 

I kinda agree on the improvement to their effiency designs being disappointing. They're disappointing considering the 5 years between announcements. The jump is small considering the time frame. With that being said: it's a game of trade-offs when you try to improve effiency and performance at the same time. They probably went for raw performance improvements over power savings costing them in the effiency department. I also dislike the 2x headline when it's a big asterisk considering it's in one benchmark among many.

[suicidalfranco]

Did someone from nvidia draw those graphs ?

[LAwLz]

2 hours ago, Trixanity said:

I'm quite sure Anandtech said that in their A10 write-ups but I could be wrong. Since all the other players did the same in their first attempt I guess you want to slowly shift your designs to get rid of bugs and other problems in the implementation before you go all in.

Nope you're right. Anandtech says that it is cluster switching.

Quote

Meanwhile it should be noted that while A10 technically has four CPU cores – the two Hurricane cores and the two smaller cores – this is not a heterogeneous design, and only two cores are active at once.

 

 

That's strange, considering Samsung very quickly moved to HMP.

I can't remember if the CCI issues prevented them from software updating the 5410 to support HMP, or if they released a new version with it fixed (5420), but by the time the Note 3 was released (like half a year after the first big.LITTLE chip came out) they had everything fixed. It seems weird that Apple would release a poor implementation like that if all they needed were a few more months of work (which should have been accounted for during the planning phase of development).

I wonder what their reason was.

[Juanitology]

12 hours ago, Sampsy said:

What a truly awful set of slides. 121% increase in performance -> Make the bar twice as long. 197% increase -> Make the bar 5x as long. 

I'm kinda ok when at least they mark where 100% is and put proper scale breaks but this is just pure undiluted marketing bullshit. 

[RedRound2]

8 hours ago, LAwLz said:

Nope you're right. Anandtech says that it is cluster switching.

 

 

That's strange, considering Samsung very quickly moved to HMP.

I can't remember if the CCI issues prevented them from software updating the 5410 to support HMP, or if they released a new version with it fixed (5420), but by the time the Note 3 was released (like half a year after the first big.LITTLE chip came out) they had everything fixed. It seems weird that Apple would release a poor implementation like that if all they needed were a few more months of work (which should have been accounted for during the planning phase of development).

I wonder what their reason was.

1

I'm not going to pretend to know what you are talking about, but isn't it better to have only two cores active at a time than a possible overlap in waketime between all four cores which would result in a momentarily higher power consumption?

[LAwLz]

2 hours ago, RedRound2 said:

I'm not going to pretend to know what you are talking about, but isn't it better to have only two cores active at a time than a possible overlap in waketime between all four cores resulting in a momentarily higher power consumption?

Well it would result in higher power consumption, but that power could be put to good use. 

If you were running some highly demanding task the you could momentarily activate all 4 cores. Like you said, it would consume more power but the task would be done quicker, so it would be a better user experience. It could also help race to sleep so the power difference might not be too big. 

 

The biggest benefit is that you could put low power tasks on a LITTLE core, such as updating a messenger thread, while having a big core doing something like running an app. In Apple's current implementation, you can not mix and match between LITTLE and big cores. So in my example the workload for audio controls would be put on the big core too, instead of a LITTLE one. That's wasted power.

[RedRound2]

1 minute ago, LAwLz said:

Well it would result in higher power consumption, but that power could be put to good use. 

If you were running some highly demanding task the you could momentarily activate all 4 cores. Like you said, it would consume more power but the task would be done quicker, so it would be a better user experience. It could also help race to sleep so the power difference might not be too big. 

 

The biggest benefit is that you could put low power tasks on a LITTLE core, such as updating a messenger thread, while having a big core doing something like running an app. In Apple's current implementation, you can not mix and match between LITTLE and big cores. So in my example the workload for audio controls would be put on the big core too, instead of a LITTLE one. That's wasted power.

3

I personally don't think this is the case

 

If say all you are doing is scrolling through messages, notifications, etc the LITTLE core can handle it

But if as you said we are doing something that's a bit too much for LITTLE core, then the BIG core can fully take over and easily handle everything concurrently given how good Apple's chips are. If this is the case, then you're also saving power by keeping the LITTLE disabled. And given there really aren't any performance hiccups on the latest iOS devices, it's safe to assume that the BIG chip can indeed handle alot more

 

Probably one of the reasons why Android phones sometimes require both the sets running is probably due to the fact that the big chip alone can't handle everything without bottlenecking

[LAwLz]

30 minutes ago, RedRound2 said:

I personally don't think this is the case

 

If say all you are doing is scrolling through messages, notifications, etc the LITTLE core can handle it

But if as you said we are doing something that's a bit too much for LITTLE core, then the BIG core can fully take over and easily handle everything concurrently given how good Apple's chips are. If this is the case, then you're also saving power by keeping the LITTLE disabled. And given there really aren't any performance hiccups on the latest iOS devices, it's safe to assume that the BIG chip can indeed handle alot more

 

Probably one of the reasons why Android phones sometimes require both the sets running is probably due to the fact that the big chip alone can't handle everything without bottlenecking

Well, I think you're imagining performance the wrong way.

Performance is not some threshold where once you get up to that level of performance, all improvements are just wasted. There are a ton of tasks on iOS which would benefit from higher performance. But the big benefit from HMP is not the extra performance. The biggest benefit is the higher dynamic range of both power and performance you get. Cluster migration has far more rigid power and performance states, and being able to address each core individually makes the OS better at adapting the core configuration for any particular workload.

It really doesn't have anything to do with "Apple's big cores are so good they can handle everything, while Android phones are bad and need every help it can get". HMP is strictly better for both power and performance reasons, and I am sure that Apple are already working on implementing it.

 

It's about not running trivial background tasks on a big and power hungry core. It's not a question of which core can handle it in terms of performance. It's about using the core that is the most efficient for a given task. Right now you are running into situation on iOS where a task should be scheduled on a LITTLE core, because that would not impact performance in any meaningful way, and it would save power, but because a big core is already active the task will be assigned to that instead, thus wasting power.

There are also instances where both big cores are maxed out, but the LITTLE cores are just sitting there idling. That little extra push from the LITTLE cores could help the big ones go into an idle state quicker. So not only would the task execute faster, but it would not waste as much energy as you might think. And yes, there are scenarios like these in iOS all the time. You run into a lot of them without even thinking about it. A lot of progress/loading bars for example could be shortened by more CPU power.

[Trixanity]

37 minutes ago, RedRound2 said:

I personally don't think this is the case

 

If say all you are doing is scrolling through messages, notifications, etc the LITTLE core can handle it

But if as you said we are doing something that's a bit too much for LITTLE core, then the BIG core can fully take over and easily handle everything concurrently given how good Apple's chips are. If this is the case, then you're also saving power by keeping the LITTLE disabled. And given there really aren't any performance hiccups on the latest iOS devices, it's safe to assume that the BIG chip can indeed handle alot more

 

Probably one of the reasons why Android phones sometimes require both the sets running is probably due to the fact that the big chip alone can't handle everything without bottlenecking

It's not so much the issue of what cores handle which task; it's the issue of having the flexibility to put load on the cores you need.

 

Moving to a HMP design doesn't mean all four cores necessarily need to operate at the same time but it gives you the option if it's needed. What it also allows is for one small core and one big core to be on therefore saving power instead of having to choose which cluster you wish to employ; either option is not ideal but you run into the problem of having to choose the lesser evil.

 

Don't get me wrong. No one can take anything away from Apple's chip design or their software optimization but cluster switching is an odd choice and I can't for the life of me think of a single advantage over HMP but then again: I'm not an engineer.

[LAwLz]

18 minutes ago, Trixanity said:

No one can take anything away from Apple's chip design or their software optimization but cluster switching is an odd choice and I can't for the life of me think of a single advantage over HMP but then again: I'm not an engineer.

Well, complexity is a drawback of HMP. Both on the hardware and software side.

But yeah, Apple will most likely implement it ASAP. Maybe with the next iPhone.

[Prysin]

i can't wait for the new LEG CPU and GPU to arrive