Running tasks on E cores can use a third of the energy of P cores
eclecticlight.co
eclecticlight.co
>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-perfo...
Android would not have that kind of close optimization so it is unclear if the performance would benefit from the A-series chips.
Yet still RISC-V has so far to go to even start to compete. This stuff is not easy. But wow, after a decade of thinking arm may some day turn the corner & start delivering (amd "seattle" a1100 anyone?), I see so little hope for this plodding lumbering archticture. It has been designed/refined to sell flagship phones (now well over $1000) and fuck all the rest.
Rockchip seems to be the only company even making a consumer-available arm core of any note at all, and the only systems we're seeing on the radar are nearly $200 A76's. With like 1/20th the connectivity/io bandwidth we get from a cheaper celeron system.
x86 keeps getting better. Arm archticture & cores are just defined by a bunch of miserly vultures keeping the cellphone market in thrall, the incremental of incrememtalist gains. Moore's law is getting more complex but is fine. ARM just is nads, worthless.
[1] https://www.anandtech.com/show/16693/arm-announces-mobile-ar...
Qualcomm's Snapdragon 888 is not a design from a decade ago, nor is it fabbed on a process node from a decade ago. It's Qualcomm's current flagship, regardless of the design choices they make.
Also, ARM's successor A510 efficiency cores that Qualcomm is expected to ship this year don't sound like they will be an improvement on power efficiency.
>We’ll have to wait for the new generation SoCs to actually hit the market for us to test the new A510 cores, but if indeed they come with larger power consumption operating points to achieve higher performance, then Arm won't be much nearer in catching up to what Apple has been doing with their efficiency cores. As of the latest generation of SoCs, Apple’s efficiency cores were around 4x faster than any Cortex-A55 based SoC. Which, running at roughly the same system active power, also made them 3-4x more efficient in the traditional benchmarks. As presented, a theoretical A510 SoC won't be able to close that efficiency gap at all.
https://www.anandtech.com/show/16693/arm-announces-mobile-ar...
This is pretty rare; the fastest algorithm is almost always the most efficient.
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-...
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.
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).
A second case is where a vendor offers "unlimited" backups for a flat price. This creates an incentive for the vendor to make an INCREDIBLY inefficient backup client that consumes substantial ram and CPU resources locally and minimal storage remotely. Typically this means that you aren't allowed to use more efficient clients, and have to use the vendors client. Here's looking at you crashplan.
echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load
There's room to tune more. In the old days I would start large jobs (large builds, etc) with nice so they wouldn't interfere with interactive use. Now they would run slower instead of fast-but-yielding. I can always flip ignore_nice_load off if I want the old behavior for competing fast jobs.
It's an easy 80% solution, especially because most indexers and backups come preconfigured to run nice.
It’s entirely possible that Apple has written things like the spotlight indexer to explicitly make sure they run that way as well, or it may just be an intentional result of the policy.
Cgroups can be used to limit the maximum amount of CPU bandwidth a certain group can use in a given period with fairly high resolution. For example, you can use the cpu.max variable to limit a group to run for a maximum of 1000 microseconds per second (1s = 1000000us). You can also limit what cores the group can run on, and the "weight" of the group when CPU bandwidth is being contested by other groups!
Cgroups can also limit resources such as RAM, swap and IO in a similar way.
Systemd has some features to put daemons in cgroups and provides ways to set the various control variables which is pretty handy, and it also has a way to launch regular programs with resource controls applied with systemd-run. There is also libcgroup and the sysfs interface for systems without systemd.
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.
With light and simple software (libraries)
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?
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.
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.
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).