Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Thursday March 23 2017, @07:23PM   Printer-friendly
from the big.Little-just-couldn't-decide dept.

ARM will replace the big.LITTLE cluster design with a new one that allows up to 8 CPU cores per cluster, different types of cores within a cluster, and anywhere from one to many (unlimited?) clusters:

The first stage of DynamIQ is a larger cluster paradigm - which means up to eight cores per cluster. But in a twist, there can be a variable core design within a cluster. Those eight cores could be different cores entirely, from different ARM Cortex-A families in different configurations.

Many questions come up here, such as how the cache hierarchy will allow threads to migrate between cores within a cluster (perhaps similar to how threads migrate between clusters on big.Little today), even when cores have different cache arrangements. ARM did not yet go into that level of detail, however we were told that more information will be provided in the coming months.

Each variable core-configuration cluster will be a part of a new fabric, with uses additional power saving modes and aims to provide much lower latency. The underlying design also allows each core to be controlled independently for voltage and frequency, as well as sleep states. Based on the slide diagrams, various other IP blocks, such as accelerators, should be able to be plugged into this fabric and benefit from that low latency. ARM quoted elements such as safety critical automotive decisions can benefit from this.

A tri-cluster smartphone design using 2 high-end cores, 2 mid-level cores, and 4 low-power cores could be replaced by one that uses all three types of core in the same single cluster. The advantage of that approach remains to be seen.

More about ARM big.LITTLE.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1, Redundant) by FatPhil on Thursday March 23 2017, @07:57PM (3 children)

    by FatPhil (863) <reversethis-{if.fdsa} {ta} {tnelyos-cp}> on Thursday March 23 2017, @07:57PM (#483372) Homepage
    My understanding, from people who do little things like maintain (as in the real official maintainers of) the linux kernel for arm-based chip families, and power-management subsystems, is that big.LITTLE isn't even fully working yet, despite it being several years old, and that the more complicated designs (such as min.med.max, as covered here a couple of weeks ago) have no power-saving benefit over a big.LITTLE design.

    Previous slideware not delivering what was promised, therefore introduce new slideware with even bigger promises?

    ARM ain't what they used to be a half a decade or so ago, they're turning into proper bullshit artists.
    --
    Life is a precious commodity. A wise investor would get rid of it when it has the highest value.
    Starting Score:    1  point
    Moderation   -1  
       Redundant=1, Total=1
    Extra 'Redundant' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   1  
  • (Score: 2) by bob_super on Thursday March 23 2017, @08:52PM (2 children)

    by bob_super (1357) on Thursday March 23 2017, @08:52PM (#483389)

    If you do industrial embedded designs, you customize your tasks and scheduler to properly use the right cores. BIG.little and similar schemes are great.

    If you do general computing, good luck figuring out the universal rule for Extremely Varied Apps With Greedy Coders ("I'll run the clock on the A72 so my user doesn't feel any lag").

    • (Score: 2) by FatPhil on Friday March 24 2017, @08:02AM (1 child)

      by FatPhil (863) <reversethis-{if.fdsa} {ta} {tnelyos-cp}> on Friday March 24 2017, @08:02AM (#483563) Homepage
      Nit - it's big.LITTLE, not BIG.little. And yes, I know how you're supposed to make use of it in theory, but my point is that it's still not delivering all of the benefits that were promised. "Customising the scheduler" isn't something that you can just do on a lazy friday afternoon, teams of dozens of engineers working for years still haven't got it right. I know, I've worked with them. I have about 3 years of being a linux kernel developer, in an ARM SoC environment, on my CV.
      --
      Life is a precious commodity. A wise investor would get rid of it when it has the highest value.