I measured the BinarySearch algorithm. As espected is it θ(log n ):

I had to change the test machine because of hardware problems. A new test machine has assembled (an old single core PC).

Energon on this machine is 217.54 J with a StdDev=6.28.

I also re-run the k-energon test (which I renamed "n-energa"):

as expected, n-energa is θ(n).

Looking closely at the testing environment we can note that some energy is spent outside of the tested algorithm (std::getline, std::cout, networking).

Our cost model can be refined as follows:

Where Jsetup ithe energy drawn by the testing environment, is a constant value that does not depend on the algorithm (std::getline, std::cout, networking)

We must then calculate Jsetup every time we setup a new testing environment.

We apply this formula to each test in the k-Energon test set: i=k|k>1, j=1

The average value is Jenergon(1)=Energon=310.95 J, with Standard Deviation = 4.54

The average value is Jsetup=9.04 J, with Standard Deviation = 4.53.

Expressing every test in the refined Energon:

The average Energa/k ratio is now 1 (as expected) with standard deviation=0.01.

This demonstrates that our cost model is quite accurate.

We want now verify that in order to execute the Energon algorithm k times is needed k times the energy needed to execute the Energon algorithm 1 time, in other words:

Energon(k) = k * Energon(1)

We have modified the Energon algorithm to accept the k parameter: the number of times the algorithm itself should be executed.

The results of a set of 30 tests on k from 1 to 10:

Same results expressed in Energons:

The Energon/k ratio:

As expected the Energon/k ratio is very near to 1, which proves that

Energon(k) = k * Energon(1)

We wrote the simplest possible software, a loop consisting of a single INC Assembler instruction, it only involves CPU, memory is not involved:

The experiment has been repeated 30 times on a Pentium III, 800 MHz, 384 MB of RAM, Windows XP:

Average J used = 320

Std Dev = 1.88

From now on every other tested algorithm will be expressed in Energons, we will use the symbol e to express 1 Energon.

 “Reproducibility of experimental results is central to the scientific method” (http://en.wikipedia.org/wiki/Units_of_measurement)

We want to measure the energy drawn from a particular algorithm so we are going to read:

·         Seconds for algorithm completion

·         Average W drawn

Using an ammeter before the PC power supply we can measure the current drawn, we know that (in Italy) AC is 220V, so we are able to calculate the total J used by the algorithm:

W=I*V

J=W*t

For example if an algorithm took 2 seconds to complete and requested an average of 0.2 Amp on a 220V AC power line then it took J=W*t=(A*V)*t=(0.2amp * 220V) * 2sec = 88 J  .

Since we don’t want our results to depend on a particular system (hardware/software) we propose the creation of a new measurement unit that we’ll call Energon that will vary from system to system. Everytime we setup a testing environment, before start measuring the tested software, we have to measure the Energon on that specific system. The Energon is not an absolute value (like the meter), it is a relative value, every environment has its Energon.

We also want the unit to be easily reproducible so we decided to use the simples algorithm imaginable.

The chosen sensor is a 30Amp Phidget 1122 ammeter:

Details: http://www.phidgets.com/documentation/Phidgets/1122.pdf

Sensors specs reports a maximum error of 5%, with typical error between 1% and 2%.

We measure the current drawn by the PC running a tested software by using an ammeter and a chronometer. A second PC runs a testing software which reads an ammeter sensor and runs a chronometer. Testing software and tested software communicate through a TCP socket on a LAN.

Short term:

Long term: 

Project Energon is a Computer Science MA thesis on software energy consumption.

This blog is about problems faced and ideas involved.

We want to establish a software energy model which is:

·         Reproducible

·         Repeatable

·         Compositional

We aim to bring the software complexity from the actual theoretical to empirical field.

We also aim to build a software/hardware benchmark system based on energy consumption.