5 ms·

How soon will we have 16/32 core mobile processors? It would be nice if something will force the industry to investigate alternative parallel programming paradi

by M8 11y ago

How soon will we have 16/32 core mobile processors? It would be nice if something will force the industry to investigate alternative parallel programming paradigms.

robert_foss 11y ago
The workloads don't support that many threads. 8-core A53 chips exist, but they don't perform anywhere near what a 2-core A57 does for typical mobile workloads.
- DannyBee 11y ago
  Yes, it doesn't make a whole heck of a lot of sense to add cores when they aren't cpu bound at all. The idea that "the slow cores can just handle the background stuff" makes little to no sense in practice. The most power effective thing to do is not add more cores (and all that entails), but get done the work something wants done as fast as humanly possible so you can go back to sleep. Having slow cores handle this for you sounds great in theory. In practice, it's been a huge bust (The one exception being dedicated-function coprocessors, etc) This is one reason that, for example, higher speed wifi/etc chipsets often become less power intensive than the old chipsets (past the initial spike from it being new hardware) - they can sleep more
  - jacquesm 11y ago
    For low end servers it would make sense though.
  - CHY872 11y ago
    Do you have any numbers re "little to no sense in practice"? What I've heard suggests that the tradeoffs behind high performance ARM lead to significantly worse power efficiency to the benefit of peak performance; which means that a core like the A53 ends being a very attractive proposition for power saving. Certainly I don't know why ARM would recommend their big.LITTLE architecture (or at least why people would use it) unless it did. Furthermore, Amdahl's law means that even in theory it should be advantageous for performance to include a few extra low power cores to boost peak performance (above adding a larger high power core).
    - DannyBee 11y ago
      "Certainly I don't know why ARM would recommend their big.LITTLE architecture (or at least why people would use it) unless it did. " Because they want to compete with others who keep upping the core numbers. "Furthermore, Amdahl's law means that even in theory it should be advantageous for performance to include a few extra low power cores to boost peak performance (above adding a larger high power core)." Again, in practice, exactly zero of the chips that have done this and been put in phones (nvidia's, etc) have actually saved power by doing so. Or did things get miraculously better when nobody was looking?
  - pcwalton 11y ago
    > The most power effective thing to do is not add more cores (and all that entails), but get done the work something wants done as fast as humanly possible so you can go back to sleep. And what if you can actually scale your CPU-bound tasks linearly? Then you can use the extra cores to get the work done faster so you can go back to sleep faster. I'm not speculating here: I've seen power measurements demonstrating this in real world applications on mobile (in my case, the browser engine). If you can use all your cores to get the work done faster, you can decrease overall power consumption. You're assuming we aren't going to parallelize our applications. I don't make that assumption.
    - DannyBee 11y ago
      "You're assuming we aren't going to parallelize our applications. I don't make that assumption. " I'm assuming parallelizing doesn't help enough :) Which it hasn't so far. So let me rephrase "so far, it makes no sense". and it's not like they haven't existed for quite a while, so it's not "well, it's a chicken and egg problem".
      - pcwalton 11y ago
        > I'm assuming parallelizing doesn't help enough :) Which it hasn't so far. So let me rephrase "so far, it makes no sense". Not according to my numbers. And yes, we have measured the impact of parallel rendering specifically on power consumption on mobile. On real-world Web sites, not random microbenchmarks.
Scaevolus 11y ago
Companies aren't going to sacrifice millions of dollars to encourage development of new parallel programming techniques. Developers barely know what to do with 4 cores, especially on mobile. The usual outcome is that foreground apps use a core, maybe two if they have async rendering, and background apps can run as well. Mobile OpenCL is the closest we'll come to massively parallel programming in people's pockets for the foreseeable future.
- madez 11y ago
  It seems like you are ignorant about Servo. "We are still evaluating plans to ship Servo as a standalone product, and are focusing on the mobile and embedded spaces rather than a full desktop browser experience in the next two years." https://github.com/servo/servo/wiki/Roadmap https://github.com/servo/servo/wiki/Roadmap
  - wmf 11y ago
    Imagine how much it cost to develop Servo. Now imagine rewriting every mobile app from scratch using the lessons learned from Servo. The cost would be astronomical, and for what? Incrementally better battery life?
    - gue5t 11y ago
      Most mobile apps are native GUI wrappers around ffmpeg, some http library, and maybe WebKit or Blink. The high-level coördination will remain relatively unchanged as the underlying GUI, media, network, and web libraries push up against Amdahl's law.
      - pcwalton 11y ago
        And don't forget the king of multicore-scalable APIs: OpenGL. The reason why GPU manufacturers have been able to scale so well by adding more cores is that GLSL provides a programming model that scales broadly to (more or less) any number of cores, and applications are written to that model. This allows applications to run unmodified on new hardware with more cores and see speedups.
CHY872 11y ago
We probably won't for a very long time. Many of the architectural designs that sit behind current processors would have to be entirely rethought. For example snoopy caches would I think stop scaling by that point, and in order to fit the cores onto the chip you'd probably have to get rid of a lot of the control flow logic (superscalar, branch predictor), so you'd lose a tonne of performance on singlethreaded code. You really don't want to move onto 16 cores unless you have to. More likely is more powerful instructions (perhaps true vector instructions).

by M8 11y ago

How soon will we have 16/32 core mobile processors? It would be nice if something will force the industry to investigate alternative parallel programming paradigms.

robert_foss 11y ago

The workloads don't support that many threads. 8-core A53 chips exist, but they don't perform anywhere near what a 2-core A57 does for typical mobile workloads.

DannyBee 11y ago
Yes, it doesn't make a whole heck of a lot of sense to add cores when they aren't cpu bound at all. The idea that "the slow cores can just handle the background stuff" makes little to no sense in practice. The most power effective thing to do is not add more cores (and all that entails), but get done the work something wants done as fast as humanly possible so you can go back to sleep. Having slow cores handle this for you sounds great in theory. In practice, it's been a huge bust (The one exception being dedicated-function coprocessors, etc) This is one reason that, for example, higher speed wifi/etc chipsets often become less power intensive than the old chipsets (past the initial spike from it being new hardware) - they can sleep more
- jacquesm 11y ago
  For low end servers it would make sense though.
- CHY872 11y ago
  Do you have any numbers re "little to no sense in practice"? What I've heard suggests that the tradeoffs behind high performance ARM lead to significantly worse power efficiency to the benefit of peak performance; which means that a core like the A53 ends being a very attractive proposition for power saving. Certainly I don't know why ARM would recommend their big.LITTLE architecture (or at least why people would use it) unless it did. Furthermore, Amdahl's law means that even in theory it should be advantageous for performance to include a few extra low power cores to boost peak performance (above adding a larger high power core).
  - DannyBee 11y ago
    "Certainly I don't know why ARM would recommend their big.LITTLE architecture (or at least why people would use it) unless it did. " Because they want to compete with others who keep upping the core numbers. "Furthermore, Amdahl's law means that even in theory it should be advantageous for performance to include a few extra low power cores to boost peak performance (above adding a larger high power core)." Again, in practice, exactly zero of the chips that have done this and been put in phones (nvidia's, etc) have actually saved power by doing so. Or did things get miraculously better when nobody was looking?
- pcwalton 11y ago
  > The most power effective thing to do is not add more cores (and all that entails), but get done the work something wants done as fast as humanly possible so you can go back to sleep. And what if you can actually scale your CPU-bound tasks linearly? Then you can use the extra cores to get the work done faster so you can go back to sleep faster. I'm not speculating here: I've seen power measurements demonstrating this in real world applications on mobile (in my case, the browser engine). If you can use all your cores to get the work done faster, you can decrease overall power consumption. You're assuming we aren't going to parallelize our applications. I don't make that assumption.
  - DannyBee 11y ago
    "You're assuming we aren't going to parallelize our applications. I don't make that assumption. " I'm assuming parallelizing doesn't help enough :) Which it hasn't so far. So let me rephrase "so far, it makes no sense". and it's not like they haven't existed for quite a while, so it's not "well, it's a chicken and egg problem".
    - pcwalton 11y ago
      > I'm assuming parallelizing doesn't help enough :) Which it hasn't so far. So let me rephrase "so far, it makes no sense". Not according to my numbers. And yes, we have measured the impact of parallel rendering specifically on power consumption on mobile. On real-world Web sites, not random microbenchmarks.

Scaevolus 11y ago

Companies aren't going to sacrifice millions of dollars to encourage development of new parallel programming techniques. Developers barely know what to do with 4 cores, especially on mobile. The usual outcome is that foreground apps use a core, maybe two if they have async rendering, and background apps can run as well. Mobile OpenCL is the closest we'll come to massively parallel programming in people's pockets for the foreseeable future.

madez 11y ago
It seems like you are ignorant about Servo. "We are still evaluating plans to ship Servo as a standalone product, and are focusing on the mobile and embedded spaces rather than a full desktop browser experience in the next two years." https://github.com/servo/servo/wiki/Roadmap https://github.com/servo/servo/wiki/Roadmap
- wmf 11y ago
  Imagine how much it cost to develop Servo. Now imagine rewriting every mobile app from scratch using the lessons learned from Servo. The cost would be astronomical, and for what? Incrementally better battery life?
  - gue5t 11y ago
    Most mobile apps are native GUI wrappers around ffmpeg, some http library, and maybe WebKit or Blink. The high-level coördination will remain relatively unchanged as the underlying GUI, media, network, and web libraries push up against Amdahl's law.
    - pcwalton 11y ago
      And don't forget the king of multicore-scalable APIs: OpenGL. The reason why GPU manufacturers have been able to scale so well by adding more cores is that GLSL provides a programming model that scales broadly to (more or less) any number of cores, and applications are written to that model. This allows applications to run unmodified on new hardware with more cores and see speedups.

CHY872 11y ago

We probably won't for a very long time. Many of the architectural designs that sit behind current processors would have to be entirely rethought. For example snoopy caches would I think stop scaling by that point, and in order to fit the cores onto the chip you'd probably have to get rid of a lot of the control flow logic (superscalar, branch predictor), so you'd lose a tonne of performance on singlethreaded code. You really don't want to move onto 16 cores unless you have to. More likely is more powerful instructions (perhaps true vector instructions).