Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ARM Launches DynamIQ: big.Little to Eight Cores Per Cluster

anandtech.com

Post reply on HN
Print view View original

1–10 of 18 posts

Re: ARM Launches DynamIQ: big.Little to Eight Cores Per Cluster

#2

Post by DiabloD3 »

I wonder when Intel is going to attempt their own version of big.little.

I think there is a market for laptop and thin-desktop x86 CPUs that are asymmetric 2 core/4 thread big + 2 core/2 thread little, and they already have a small version of their modern cores[1], so a 2 full Skylake + 2 little Goldmont cores (or 4+4) could be extremely interesting, especially on a future 115x socket.

  1.
  * Silvermont (Bay Trail/Avoton/Rangeley) == "atomfied" Haswell
  * Airmont (Braswell/Cherry Trail) == "atomfied" Broadwell
  * Goldmont (Apollo Lake/Denverton) == "atomfied" Skylake
  * ???mont (Gemini Lake) == "atomfied" Kaby/Coffee Lake.

Re: ARM Launches DynamIQ: big.Little to Eight Cores Per Cluster

#3

Post by Symmetry »

DiabloD3 wrote: post #2

I wonder when Intel is going to attempt their own version of big.little. I think there is a market for laptop and thin-desktop x86 CPUs that are asymmetric 2 core/4 thread big + 2 core/2 thread little, and they already have a small version of their modern cores[1], so a 2 full Skylake + 2 little Goldmont cores (or 4+4) could be extremely interesting, especially on a future 115x socket. 1. * Silvermont (Bay Trail/Avot…

The problem with Intel doing this is that, for marketing reasons, they tend to enable different sets of instructions on different cores and an OS would have a really hard time scheduling threads when some the Skylake cores can execute AVX instructions but the Goldmont cores can't. Normally the scheduler wants to assume that it can just move a thread from one core to another but if the thread started off on the Skylake and was taking an AVX-enabled code path that would cause problems.

Not that the idea isn't appealing or even infeasible. It just runs afoul of Intel's marketing.

Re: ARM Launches DynamIQ: big.Little to Eight Cores Per Cluster

#6

Post by microcolonel »

Symmetry wrote: post #3
DiabloD3 wrote: post #2

I wonder when Intel is going to attempt their own version of big.little. I think there is a market for laptop and thin-desktop x86 CPUs that are asymmetric 2 core/4 thread big + 2 core/2 thread little, and they already have a small version of their modern cores[1], so a 2 full Skylake + 2 little Goldmont cores (or 4+4) could be extremely interesting, especially on a future 115x socket. 1. * Silvermont (Bay Trail/Avot…

The problem with Intel doing this is that, for marketing reasons, they tend to enable different sets of instructions on different cores and an OS would have a really hard time scheduling threads when some the Skylake cores can execute AVX instructions but the Goldmont cores can't. Normally the scheduler wants to assume that it can just move a thread from one core to another but if the thread started off on the Skylak…

This is one of those interesting cases where RISC-V could eat their (and maybe ARM's) lunch on implementations like this. The wide vector instructions (i.e. not the packed SIMD, but the -V extension) are width-independent, so you could just make the vector machine narrower on the little core, and switch it to low-frequency in-order.

Re: ARM Launches DynamIQ: big.Little to Eight Cores Per Cluster

#7

Post by Symmetry »

microcolonel wrote: post #6
Symmetry wrote: post #3

Earlier quoted context omitted.

The problem with Intel doing this is that, for marketing reasons, they tend to enable different sets of instructions on different cores and an OS would have a really hard time scheduling threads when some the Skylake cores can execute AVX instructions but the Goldmont cores can't. Normally the scheduler wants to assume that it can just move a thread from one core to another but if the thread started off on the Skylak…

This is one of those interesting cases where RISC-V could eat their (and maybe ARM's) lunch on implementations like this. The wide vector instructions (i.e. not the packed SIMD, but the -V extension) are width-independent, so you could just make the vector machine narrower on the little core, and switch it to low-frequency in-order.

ARM recently added a similar wide vector instruction called SVE which works similarly. But yes, that way of doing vectors is really cool.

EDIT: Come to think of it, this might be something ARM has been adding deliberately partially to be able to use hetrogenous cores.

Re: ARM Launches DynamIQ: big.Little to Eight Cores Per Cluster

#9

Post by Narishma »

pjmlp wrote: post #8

A better source of information than Anandtech, including a reference to the presentation slides. https://community.arm.com/processors/b/blog/posts/arm-dynami... https://community.arm.com/processors/b/blog/posts/arm-dynami...

I'm not sure about 'better'. Those links are full of buzzwords and marketing speak.

Re: ARM Launches DynamIQ: big.Little to Eight Cores Per Cluster

#10

Post by brianwawok »

Symmetry wrote: post #3
DiabloD3 wrote: post #2

I wonder when Intel is going to attempt their own version of big.little. I think there is a market for laptop and thin-desktop x86 CPUs that are asymmetric 2 core/4 thread big + 2 core/2 thread little, and they already have a small version of their modern cores[1], so a 2 full Skylake + 2 little Goldmont cores (or 4+4) could be extremely interesting, especially on a future 115x socket. 1. * Silvermont (Bay Trail/Avot…

The problem with Intel doing this is that, for marketing reasons, they tend to enable different sets of instructions on different cores and an OS would have a really hard time scheduling threads when some the Skylake cores can execute AVX instructions but the Goldmont cores can't. Normally the scheduler wants to assume that it can just move a thread from one core to another but if the thread started off on the Skylak…

Couldn't you engineer the little core to take the fat instruction it can't process and instead do many small instructions to get the same end result? I am specifically thinking of AVX here, and it seems like it would work.. but perhaps there are other instructions that would not be so easy to unroll.
Post reply on HN