This post briefly discusses some of the main contributions and limitations of the MAGEEC project and suggests several directions for future work.
It has always been the aim of the MAGEEC project to be as open as is practically possible, by making research outputs, software sources and hardware designs all freely available. Of course, hardware still needs to be manufactured and if you don’t have access to facilities for doing this the setup costs associated with third party services can be prohibitive for just one or a few boards.
I set out to examine our current choice of features to be extracted from benchmarks, using a process called PCA (Principle Component Analysis). I used BEEBS as a source of programs, since it has been designed to represent a large range of different types of programs and would help me evaluate the feature thoroughly.
Greetings! I am Stoil Ganev, a Computer Science student at the University of Bristol and I am working on the MAGEEC project over this summer.
One of my main responsibilities is to find systems that are most likely to have practical benefits from energy optimisations on their software and then study the effect of MAGEEC on their real world applications. For example, I have looked at systems which have a limited power supply or an unreliable one such as batteries and solar panels. Example benefits for such systems may be increased battery time, the ability to use smaller solar panels or keeping energy consumption low enough for solar panels to keep up in rainy periods. Also, these systems have to be open source both hardware and software wise so that I can construct them and compile their source code using MAGEEC.
In order to train the machine learner that is central to MAGEEC, a large data set is required relating energy measurements and compiler optimisation passes. Our benchmarking suite, BEEBS, is comprised of 93 applications (correct at the time of writing), and is continuing to expand. Similarly, our current count of trivially optional optimization passes in GCC (for an AVR platform) is 120. If we consider a full factorial design, whereby we run a test for every possible configuration of compiler passes, for each benchmark, clearly the experiment will be enormous in scope. Therefore, it is in our interest to analyse the effects of each compiler pass on a per architecture basis, in order to determine which have negligible effect on energy consumption. To achieve this, as part of my contribution to the MAGEEC project this Summer, I will be working on implementing a Plackett-Burman design.
Hello, my name is Greg Cawthorne, I’m with the MAGEEC project from 18th June to around September 4th and will be working with the team at Embecosm along with my peers at Bristol University.
In this first blog post I shall discuss what work has been done thus far — mainly around Machine Learning and collecting energy readings — as well as where I shall be doing further research and have potential routes to explore in terms of improvement.
One of the goals of MAGEEC is to work with real measurement data for the machine learner to train on. As it has been shown in a previous blog post, we have our own measurement board and a python library to easily work with it. The next step is naturally to take measurements on various platforms and various relevant programs. This is where the Bristol/Embecosm Embedded Energy Benchmark Suite comes in, or BEEBS for short.
As part of the MAGEEC we need an energy measurement infrastructure for a couple things: taking measurements for the machine learner to train on, and measurements to evaluate the decisions that the machine learner has made. Furthermore, we want to be able to do this over many platforms, with minimal human interaction and in a convenient way. This leads to the creation of a hardware platform, and a software framework to support it and that allows for easy interaction with the board.
On January 2nd, as part of our community engagement, we hosted the Energy Efficient Computing developer room at FOSDEM 2014 in Brussels. At which members of the MAGEEC team and others shared details of the latest developments in measuring and reducing the energy consumed by computer systems.
The day started off with Jeremy Bennett giving a recap of the main track talk that he and Kerstin Eder had given the previous day — “Who ate my battery?”— to set the scene for the talks that would follow. These included a background to energy measurement from Simon Hollis, a talk on the MAGEEC energy measurement platform from James Pallister, and a broader introduction to MAGEEC from myself.
My talk marked the first discussion of the concepts and implementation of MAGEEC given to developers outside the compiler specialty; most talks up until now have been given at conferences such as GNU Tools Cauldron and LLVM Developers Meeting. There were questions after the talk on similar work in this area, and I’m pleased to say that our work was well received, with a general view that what we are doing is particularly interesting by nature of being universally applicable to virtually all architectures and compilers. A link to the talk will be added once it is available.
Not that the entire dev room was about MAGEEC and other talks covered numerous aspects in the field of low energy computing. Kyriakos Georgiou and Neville Grech spoke about ENTRA, which aims to produce energy information as part of compilation, similar to how code size is currently provided. David Greaves from University of Cambridge Computer Laboratory gave a talk about spEEDO, which links energy data with debugging info, in order to report energy usage in systems. Emilio Monti spoke about the low energy mbed platform, and Hayden Field and James Pedlingham spoke about EACOF, which combines energy data from multiple sources, presenting it to a program or user in a usable manner.
In the middle of day we ran a workshop which allowed delegates to get hands-on with the energy measuring hardware and enabled them to see for themselves how the software they develop affects energy consumption. At the end of the 3 hour workshop we gave away 50 energy measurement kits and encourage their new owners to put them to use in creating energy-efficient software. And of course, it wouldn’t be a proper open hardware workshop without some hardware being hacked!
To accompany the dev room and to increase awareness of the project, we also ran a two-day stand focusing on MAGEEC and other low-energy projects at Embecosm and University of Bristol. At the stand we gave demonstrations of the energy measurement boards and members of the MAGEEC team were on hand to discuss software energy consumption in general.
Overall, as an open source software and hardware project, FOSDEM was a natural fit to discuss the project and concepts at large, and we are delighted with the response we had both over the course of the weekend and follow up discussions since then via e-mail. This forms just part of our plans for making energy-efficient computing a talking point, and enabling people to measure energy consumption and to make their software use less energy. We will be participating at more events and will share details as soon as our plans develop.
This post considers the question of whether it is possible to obtain C code for the tasks exemplified in the well-known Numerical Recipes in C series so it can be used in a public benchmark repository that be used under a sensible license. Although the Numerical Recipes series is very well-known, its licensing restrictions mean that the GNU Scientific Library (GSL) seems to be a more likely source of such benchmarks. This short post briefly considers the Numerical Recipes, Netlib and GSL resources.