On 4 July 2013 17:13, Siarhei Siamashka siarhei.siamashka@gmail.com wrote:
By the way, power consumption is not constant and heavily depends on what the CPU is actually doing. And 100% CPU load in one application does not mean that it would consume the same amount of power as 100% CPU load in another application.
This is really interesting, I had not considered it until now. If I understood correctly, this has to do with what/how many paths are taken inside the cores (CPU, GPU), or how much data is passing between mem/cache/registers, etc.
For toolchain, there isn't much of floating going on, but if your compiler was auto-vectorized, you'll probably be using NEON, and there will be a lot of data movement, too, so I'm guessing compilers can stretch quite a lot the CPU overall. And since building a large project (like GCC or LLVM) takes several hours with very little happening outside the CPU, there isn't much time to cool down the CPU between compilation jobs.
Some time ago, I tossed my Cortex-A9 cpuburn to the ODROID-X people. And coincidentally they quickly got the thermal framework properly integrated into their kernels and also started to offer optional active coolers to their customers :-)
Hahahaha! Yes, that's what I'm talking about. I don't think anyone did that with Pandas or Arndales, and somebody really should.
In my opinion, the right
solution for modern ARM SoCs is just to always ensure proper throttling support (both in the hardware and in the software). ARM can even call it "turbo-boost", "turbo-core" or use some other marketing buzzword ;-)
Absolutely! Though, while throttling is the way to go, it might be simple to wait for it with a decent cooling solution than with a lower frequency. ODroid folks seem to have understood that pretty well.
It would be a lot easier to convince hardware vendors and cluster builders to buy huge active coolers, than convince them to lower the CPU frequency. The former show failure in software support, but the latter show failure in system design...
cheers, --renato
On 4 July 2013 18:10, Renato Golin renato.golin@linaro.org wrote:
On 4 July 2013 17:13, Siarhei Siamashka siarhei.siamashka@gmail.com wrote:
By the way, power consumption is not constant and heavily depends on what the CPU is actually doing. And 100% CPU load in one application does not mean that it would consume the same amount of power as 100% CPU load in another application.
This is really interesting, I had not considered it until now. If I understood correctly, this has to do with what/how many paths are taken inside the cores (CPU, GPU), or how much data is passing between mem/cache/registers, etc.
Modern CPU designs can even clock-gate partial pipelines when not in use. Typical code doesn't even use the multiply pipeline most of the time, so it will spend a lot of time gated. A carefully crafted piece of code, like Siarhei's, maintains the maximum sustained issue rate for a long time, and mixes instructions such that most of the pipelines are active most of the time. This makes the power consumption go up significantly.
It would be a lot easier to convince hardware vendors and cluster builders to buy huge active coolers, than convince them to lower the CPU frequency.
Chips intended for compute clusters will no doubt be possible to cool sufficiently to run at full speed all the time. Designing chips for different markets involves different sets of tradeoffs, and you're seeing the result of that.
On 4 July 2013 19:15, Mans Rullgard mans.rullgard@linaro.org wrote:
Chips intended for compute clusters will no doubt be possible to cool sufficiently to run at full speed all the time. Designing chips for different markets involves different sets of tradeoffs, and you're seeing the result of that.
Yes, this is what I'm trying to get at. For toolchain testing we need a machine that doesn't give up under high constant load for really long periods (months/years). This is slightly lighter than the kind of load that you'll have when using servers like Calxeda, for uses like Facebook's. On mobile platforms, the diversity of uses is really reduced, so it's ok to make several compromises on the chip/SoC/system design to save on costs. But when ARM cores hit the desktop/server market, these assumptions will stop being valid.
This video of Linux Torvalds on why Linux haven't dominated the desktop market yet (and may never will) is relevant:
http://www.youtube.com/watch?v=ZPUk1yNVeEI
Basically, the usage patterns are so disparate between users, or even groups of users, that it's hard for any single Linux distribution / vendor to focus on all of them. ARM is similar, that itself can't focus on servers or desktops only, but if the designs allow for modularity (I believe they do), partners could (should) build SoCs focused on different markets, vendors (like HP, Dell) could put together production systems, etc.
Both ARM and Linux move into desktops would need a level of coordination between competitors that is probably not possible on today's market. (please, somebody tell me I'm wrong...)
cheers, --renato
linaro-validation@lists.linaro.org
-
Mans Rullgard -
Renato Golin