On 4 July 2013 17:13, Siarhei Siamashka <siarhei.siamas...@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
_______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
