14 ms·
Running tasks on E cores can use a third of the energy of P cores
- Kon-Peki 5y agoThese Apple Silicon chips are already very efficient, so it is pleasantly surprising to see the ability to reduce power consumption by 66%. I am wondering though - with some tasks it may be possible to implement using multiple algorithms/approaches, and that could make the differences even larger (if I am pinning to E cores, use algorithm A for maximum efficiency but if I am using P+E cores, use algorithm B for maximum performance).
- wmf 5y agouse algorithm A for maximum efficiency but use algorithm B for maximum performance This is pretty rare; the fastest algorithm is almost always the most efficient.
- Lichtso 5y agoFor purely sequential algorithms I agree, fewer work steps means less energy used and less time spent. But the picture is very different when it comes to parallel algorithms. There often is a tradeoff between doing more redundant work to reduce the latency and finish faster overall at the expense of more energy being used. One example is the "scan" operation on GPUs. There are lots of different algorithms to do it which form a gradient between fast and efficient. For reference see page 2 of this paper: https://research.nvidia.com/publication/2016-03_single-pass-parallel-prefix-scan-decoupled-look-back https://research.nvidia.com/publication/2016-03_single-pass-...
- phaedrus 5y agoFrom the title, not knowing what E and P cores are, I wondered if maybe it meant using software emulation to make a "virtual CPU core" could actually be more energy efficient than running on a physical core. And now I kinda wonder if there is something to that idea... For example I was just reading a different HN thread were people were complaining about Windows 10 randomly turning your laptop into a hairdryer when it's otherwise idle (pegging the CPU at 100% for an update or scan). It's clear a lot of software doesn't need to run at full hardware speed; maybe I'd rather these background scans use only 10% CPU and take 10 times at long. And I bet it wouldn't take 10 times as long, due to the way latency & etc. scale. Another example is a lot of software is inefficient for stupid reasons. If we had automated ways to detect the most common stupid code, maybe we just not run it (if the answer makes no difference), or run an optimized replacement. Constrained to run on a physical core, you either need static analysis or dynamic recompilation and are limited in some ways, but running on an emulated core you could do whatever you want with dirty tricks that the process can't detect.
- eternityforest 5y agoLinux file scanners are the worst for this, or were until recently. I have no idea why it was so hard not to occasionally consume 100% CPU and tons of disk IO at inconvenient times, but multiple different indexers have exactly the same issue. I bet you could static analyze to find pure functions, then add a caching layer automatically. A lot of slowness seems to be because a cache wasn't used. Or because something stateless should have been stateful(As in fully recomputing stuff that depends on previous inputs rather than calculating one item at a time).
- smoldesu 5y agoMacOS' indexer is equally as bad. The amount of time's I've seen 10 mdworker threads pinning my CPU is staggering...
- als0 5y agoAFAIK this problem seems to have gone away with the M1 based Macs. Can anyone confirm?
- smoldesu 5y agoI'd imagine it's not an issue since Grand Central Dispatch will only assign it to a single core cluster, which leaves the other cores free to do their own processing.
- ceeplusplus 5y agoI believe indexing tasks only run on e-cores, at least from quick glances at Activity Monitor. I also see more kernel code run on e-cores when I'm compiling code, not sure if Apple is moving blocking syscalls onto e-cores and swapping threads or something (intuition tells me this shouldn't lead to perf gains due to context switch cost, but who knows).
- MBCook 5y ago
- eternityforest 5y agoHardware-based efficiency stuff seems to be the future. This whole idea that we need light and simple software to be fast doesn't quite we need software that takes fullest advantage of hardware. I bet we could do a lot more with this idea. We could have dozens of tiny cores, without any math beyond addition, for things like regexes and file format parsing. We could probably fit stuff like small AIs and video codecs on SD sized accelerator chips if we really tried. It will be cool to see how far they can take this. It will also be really cool to see how we program for this kind of thing, to really make the best use of it.
- Wohlf 5y agoThis has always been a key component of processor design and has been integral to improvements in consumer device processors for a while now.
- zekrioca 5y ago> It will also be really cool to see how we program for this kind of thing, to really make the best use of it. With light and simple software (libraries)
- eternityforest 5y agoI'm guessing it will probably be more like large complicated libraries, just like now, that have 8 different implementations for different chips, heuristics for what is worth doing on GPU, etc.
- mhh__ 5y agoAI is probably the workload that VLIW has been waiting for all these years. It's suddenly efficient to have a big lump of very dumb silicon on board.
- eternityforest 5y agoI think network stuff is probably another one. You don't need any floating point or even very much cache to send 50 encrypted copies of a packet down 50 pipes, and handle some basic connection upkeep business.
- modeless 5y agoI'm not convinced that either estimate is accurate. To validate that the measurements are real they should actually run the tasks for a significant amount of time and see how much battery is used.
- astrange 5y agopowermetrics is not an estimate. Of course some other things on the system may change behavior if it’s not plugged in.
- ars 5y agoI agree - this appears to be very sensitive to the polling resolution. If you only run a task for 0.5 seconds, and you only check power usage every 0.25 seconds, you'll get an artificially high value. They need to run this for much longer, and with no breaks (moments of low power usage).
- GeekyBear 5y agoWith the M2 chip expected to debut at WWDC next month, here's the difference between the A14 efficiency cores used in the M1 and the A15 efficiency cores used in the current gen iPhones. >The core has a median performance improvement of +23%, resulting in a median IPC increase of +11.6%. The cores here don’t showcase the same energy efficiency improvement as the new A15’s performance cores, as energy consumption is mostly flat due to performance increases coming at a cost of power increases, which are still very much low. Also, when compared to the efficiency cores used in the Snapdragon 888: >The comparison against the little Cortex-A55 cores is more absurd though, as the A15’s E-core is 3.5x faster on average, yet only consuming 32% more power, so energy efficiency is 60% better. https://www.anandtech.com/show/16983/the-apple-a15-soc-performance-review-faster-more-efficient/2 https://www.anandtech.com/show/16983/the-apple-a15-soc-perfo...
- MBCook 5y agoObviously will never find out but it would be really interesting to see a 100% functional Android install on an A15 or A16 phone to see how well it runs, what kind of battery life it gets, etc.
- Tagbert 5y agoApple does a lot of optimizing of their chips for operations that are common on their operating systems. One example is that their languages use reference counting instead of garbage collection. Apple optimized specific operations on the M1 chips that are used by reference counting call and that made a big difference in overall performance. Android would not have that kind of close optimization so it is unclear if the performance would benefit from the A-series chips.
- MBCook 5y agoThat’s true. But given how much faster Apple chips are than the current crop of Snapdragon chips I’m guessing it would still be ahead running code that doesn’t optimize quite as well. Even if it came out even the energy efficiency could still mean incredible battery life when combined with the larger batteries that Android phones seem to have.
- throw10920 5y ago> Conventional wisdom, at least for SMP chips, is that this is the most efficient strategy, as it gets the task out of the way as quickly as possible. I've heard this conventional wisdom cited repeatedly in the realm of embedded devices, but I don't have any idea how it could possibly be true: in a synchronous CMOS chip, power scales with the square of voltage, and in order to push the chip to higher frequencies, you have to increase the (gate? rail?) voltage - doesn't that mean that computing things at lower frequencies is almost always more efficient?
- wmf 5y agoIt depends on the idle power.
- brigade 5y agoIf you scale frequency down far enough then leakage power can easily dominate, and a decade ago it was bad enough that race-to-idle really was more power efficient than the DVFS most SoCs could do. Vendors were so bad at this that one of ARM's largest motivations for big.LITTLE so that their partners could have any semblance of DVFS that actually saved power at lower perf states. Although, I think the blogger only measures pinning on different CPUs, not the effect of DVFS vs. race-to-idle, so his statement is a non sequitur. Because of course a power-optimized arch is going to be more efficient than a perf-optimized arch (modulo uncore power), and that's been known and true since forever.
- nagisa 5y agoRunning a core doesn't only run the core itself. There is a fair amount of supporting circuits including, but not limited to, things like memory controller, I/O bus, peripherals, etc. These can sip a non-trivial amount of power, and if a task running on an efficiency core kept them all up, you ultimately might end up with greater aggregate power use. Nowadays in modern chips these other circuits seem to be brought down to the low power states much more aggressively.
- deleted 5y ago[deleted]
- dorfsmay 5y agoI did not know about E cores and P cores on the M1. Looking into it, I found Intel is doing the same thing on their newer, 12th generation CPUs.