I took a look at the energy consumption on my laptop and the top 3 consumers were docker, slack and firefox. I only was using firefox at the time. So it got me thinking. Energy consumption per se seems to never be an issue in SW engineering. Should it be though? Has anyone else thought about it?
My building has a really poor network topology. Or no topology at all, just a mess.<p>One day, I plugged in my laptop to my ethernet socket. I noticed it got warm very quickly. After some thinking, I monitored network traffic and noticed the frequency of useless broadcast messages due to an incorrectly designed network is absolutely amazing.<p>Using powertop, I estimated this leads to 2 W of wasted energy due to frequent wakeups. Given we have hundreds of computers in the building, I can imagine the waste is not negligible.<p>Same thing applies to a misconfigured desktop. I can save 1.5 W by running a tiling window manager and no desktop environment. I can imagine that tweaking GCC flags could even bring this number down. But just sane configuration does wonders.
It’s all over the place in embedded software. If your software needs to run for a year on a coin cell battery, you basically have to turn off large sections of your processor and peripherals except when they absolutely need to run.
There most certainly is, but it tends tobe a late-bloomphenomena I've noticed. Eventually, you end up coming to terms with the fact computation is not free, and it starts to make a lot of software really, really bloated and frustrating. In fact certain software solutions that rhyme with sock drain which utilize a proof-of-work algorithm should cause one with an understanding the ramificationsof all that wasted computation blanch in embarassment if they've managed to mature past that irreverent "I'll leave the lights on if I want to" stage of life. Particularly when applied to the task of monetary or value transaction.<p>Alas, I digress. I do recall that some fanned ARM chips could actually run long enough after power was cut off to shutdown safely because the power generated by the fans spinning down was enough to keep the chip powered and processing for the most part.
Three observations:<p>First, there was a lot of research in this area in the context of minimising data center power usage. But the main players who stand to benefit from improving power consumption operate in places where power is very cheap (they specifically place their data centers in such areas) and they are also making record profits. Perhaps there isn't a huge case for power optimization economically?<p>Second, ARM is slowly gaining traction in the server market, but Intel is the leader in this field. Semiconductor companies do spend a lot of time and resources on this, perhaps alleviating the need for the problem to be dealt with in the software stack.<p>Third, CPU frequency controls are already present in the Linux OS, which is the top server OS, and quite a bit of work has gone into it. This is the main mechanism for optimizing power consumption as far as I can tell.
There was a 2017 paper "Energy Efficiency across Programming Languages: How Does Energy, Time, and Memory Relate?" <a href="https://greenlab.di.uminho.pt/wp-content/uploads/2017/09/paperSLE.pdf" rel="nofollow">https://greenlab.di.uminho.pt/wp-content/uploads/2017/09/pap...</a> .
It is in certain niche areas. For example, when working on a smartphone OS, maximizing battery life is paramount. There are specialized power measurement instruments that one attaches to the phone when trying new features / builds to verify that code changes don't cause an increase in the rate of power usage.
It used to be more of a concern. When I fist started coding in the 90s, we cared, and optimized everything. Then CPUs and memory started getting cheaper, and I often heard the mantra of "Just throw more hardware at it." Once the web took off, it became "Hey, we can just let the user's system do all the heavy lifting".<p>It is only recently that people are starting to come back to thinking about efficiency, and I thank mobile apps for that, as people do notice when a specific app is a big battery drain. That has brought back reasons to optimize your code, because battery drain can mean poor reviews, and it has a material impact on the success of your product.<p>Which is a really long way to say, "Yes, we should worry about this."
There has been some academic work in this area which concluded that energy efficiency is mostly proportional to performance. So if you want software to be energy-efficient you should basically optimize its performance (which you were probably already doing).<p>One exception to this rule is wakeups which consume disproportionate energy so they need to be optimized separately. <a href="https://wiki.ubuntu.com/Kernel/PowerManagement/IdentifyingIssues" rel="nofollow">https://wiki.ubuntu.com/Kernel/PowerManagement/IdentifyingIs...</a>
Like others have mentioned this is a thing even in not exotic embedded systems, and it should be a thing for mobile applications although many tend to neglect this aspect as you can clearly see in bad app reviews.<p>At some point of my career I actually measured milliAmps and synced it to an app waking up times using an oscilloscope, this was the core for the OS of a mobile phone.
It definitely should be. I think about it all the time.<p>Resource-hungry apps screams "unprofessional" to me. The makers (i.e. developers or company) behind these app have apparently decided for me that whatever trade off they did for my battery life/capability to multitask is worth it – without consulting me.<p>You don't need to run many such apps before even a relatively new (Intel) Macbook Air spins up the fan, gets hot and battery life plummets. Wirth's law is maddeningly real.<p>It's frankly ridiculous, considering the functional reqiurements of some of these apps – we had chat-apps comparable to Slack in the early 2000s, for goodness' sake.<p>So TLDR; Either the companies don't really care about user experience (in real contexts, i.e. using multiple apps – which most people do), or the software engineers are bad at their work.