Thursday, 30 May 2013

How does Software Go GREEN !!!

That's the next question. My theory is that green software uses the least possible amount of reusable (CPU, Network bandwidth, etc)  and non-reusable resources (RAM, ROM, Disk, etc). if one node can do the job of two, we are on our way to achieving our goal in the right direction without impacting other non-functional attributes like performance, scalability, reliability, etc in a negative way.

Lets see some examples in support of this argument from the server side:

  1. Usage of Thin-clients & cloud based VMs in enterprise computing saves energy because we save the idle power consumption (200W+) of desktops with a thin client that takes only a few watts. Multicore  and software virtualization has made this happen on the server side. from an architectural perspective, the sum of the power consumed by client, server and network for data exchange must be the least
  2. If a space (reusable-resource) bound application needs to handle increased workload, the only ways are to increase the storage (RAM, disk) or optimize the algorithm to improve the space efficiency without impacting performance. This will save an additional node and improve the performance/watt ratio for the application
  3. Similarly if a CPU (non-reusable resource) bound application has to handle twice the workload, the only way is to put a CPU with double the compute power (which may not be technically feasible at all) or reduce the CPU usage by 50%. This again saves an additional node improving the performance/watt ratio for the application
  4. If we reduce the frequency of disk writes (or we batch the writing through cache), we save power on account of saving frequent disk spin-ups and spin-downs. If we reduce the amount of dynamic data (such as logging, application data), then for every disk we save, we save 10-20W of power consumed. Space efficiency again helps here


The examples for handheld battery powered devices are more obvious (and possibly numerous), since their impact is more visible to the user in terms of improved battery life:

  1. If more of screen pixels are black than white or colored (illuminated), then we use less power. Black background on webpages and mobile applications helps. Here screen pixels is the resource
  2. Usage of event driven mechanism rather than polling (like blackberry push mail vs. Microsoft ActiveSync simulated push mail) saves power as it uses less CPU cycles and Radio.
  3. Limiting the number of background apps (like Windows Phone 8 does) preserves battery life unlike android where there is no such limit, the constraint being only available DRAM
  4. Options for email client applications like number of days of email to sync, sync frequency, amount of data to sync (subject, body, attachments) etc saves network bandwidth (radio) and CPU cycles saving power
  5. Ability to put the device in standby mode (radios switched off as well as OS hibernated like in Blackberry) during predesignated sleeping hours considerably saves power in always on smartphones
  6. Ability to switch off notifications for things like breaking news, when user is not interested saves power
  7. Decreasing the resolution of images & videos served to mobile devices saves radio power as well as CPU power
  8. Free Smartphone Apps that constantly display advertisements do so at the cost of energy efficiency as they have to constantly poll the server side for advertisements (use of Cellular/Wifi Radio) and then display it if the app is opened (uses pixels). Its a very popular business model, unfortunately its not energy efficient.


So to summarize, I offer (to begin with) that:

Software Design for Energy Efficiency = Software Design for Computing resource efficiency
Computing Resource = Reusable resource | Non-Reusable resource
Reusable Resource = RAM | Disk | Pixels etc  // Done mostly with Data Storage efficiency
Non-Reusable Resource =  CPU | Radio | Network   // Done mostly with algorithm efficiency

The overall objective is to minimize the use of computing resources required to perform a given task(s). Its just a simple doing more(or same) with less (or same) resources argument. Some would just like to equate this principle with Design For Performance. 

Why software MUST go GREEN !!!

More often than not one will come across the term "Energy Efficiency" or Energy "efficient" when reading marketing material of systems & components. And since software is a major part of most systems, one does wonder what it would mean for software itself ? 

The average software developer probably has no clue about how this concept can be applied to software. For me, at a system level energy is consumed by Hardware (not software) or is lost in transmission from the source of power generation to consumption. Based on this thought, the following inferences come to my mind:

  1. If we use less hardware (nodes, boards, disks, DRAM modules, transistors, etc for the same application) we consume less energy. And that is the case with cloud computing applications.
  2. If the hardware is put near the generation center, then probably their is less transmission loss and energy on the whole is efficiently used, even if the consuming device is just the same. Possibly that's one reason why data centers are located near hydroelectric dams or nuclear power reactors, apart from the obvious advantage of using water cooling in case of the former

While software may have little role in (2), it is an important enabler for (1). It is the demands of the software which decides what hardware is going to be used, not just better energy efficient hardware (which again requires huge energy investment in R&D). Therefore it is equally important in my opinion to write *efficient* software, rather than developing or using the most energy efficient hardware.

The situation was very different 5-10 years back. For e.g., in handheld devices (which are battery powered), software space efficiency was top-constraint, not battery capacity (mah ratings). But today we can see 3 GB of RAM in smartphones (with 4 GB round the corner) implying the space constraints have diminished while  battery life is still a big issue (reduced from 5-7 days to 1 day or lesser) while handling complex applications that make use of that RAM size. RAM size growth has outpaced battery charge holding capacity growth by many folds. Energy efficiency of software is the "pain" now, rather than how many applications we can cram into one device.

Similarly network servers were written with the provision of horizontal scaling of software, assuming the hardware is practically unlimited. If the problem gets bigger/complex, throw more hardware (and power) at it, and we are good to go again. As it turns out today power (including backup diesel generator power) is the main OPEX of service providers who run these servers. The problem will continue to get bigger and complex, but we need to put brakes on how much power is consumed, for we wont have so much or be able to afford so much.

Two radically different software development environments. Same target goal. And that's why we need to pay attention to going green with software construction.