Difference between revisions of "About"

From MAGEEC
Jump to: navigation, search
(Created page with "__NOTOC__ Welcome to MAGEEC — the MAchine Guided Energy Efficient Compiler framework. MAGEEC is an open source project which combines work on [http://arxiv.org/abs/1303.648...")
 
 
(2 intermediate revisions by 2 users not shown)
Line 3: Line 3:
  
 
MAGEEC is an open source project which combines work on [http://arxiv.org/abs/1303.6485 compilation options which save energy] with work on [http://ctuning.org/wiki/index.php?title=CTools:MilepostGCC machine learning], to create a compiler framework that is capable of generating code that has improved energy efficiency.
 
MAGEEC is an open source project which combines work on [http://arxiv.org/abs/1303.6485 compilation options which save energy] with work on [http://ctuning.org/wiki/index.php?title=CTools:MilepostGCC machine learning], to create a compiler framework that is capable of generating code that has improved energy efficiency.
 
As with many open source projects we have our own [[MAGEEC|wiki]], [[Mailing_lists|mailing lists]] and [[MAGEEC#IRC|IRC channel]], and over the coming months we'll be working to engage with the wider community.
 
  
 
== Goals ==
 
== Goals ==
Line 10: Line 8:
 
We've set ourselves four goals.
 
We've set ourselves four goals.
  
#Optimize for energy. Existing compilers optimize either to minimize execution time, or code size. This project is about generating code, which when executed will used as little energy as possible.
+
#Optimize for energy. Existing compilers optimize either to minimize execution time, or code size. This project is about generating code which when executed will used as little energy as possible.
 
#Use physical measurement of energy usage, ''not'' models. One of the problems with past projects has been using models of the amount of energy used, but these are at best accurate only to 10%, whereas individual compiler optimizations can have far smaller effects. But more importantly such models have implicit assumptions about how the processor works on which their models are based, and any compiler using such models would optimize for these assumptions, not for the actual processor.
 
#Use physical measurement of energy usage, ''not'' models. One of the problems with past projects has been using models of the amount of energy used, but these are at best accurate only to 10%, whereas individual compiler optimizations can have far smaller effects. But more importantly such models have implicit assumptions about how the processor works on which their models are based, and any compiler using such models would optimize for these assumptions, not for the actual processor.
#Be compiler agnostic — more on this below — and initially support both GCC and LLVM. One of the biggest weaknesses of the earlier MILEPOST project was that it became inextricably tied to one particular compiler, GCC, and indeed to a specific release, so making it near impossible to maintain or to be put into general use.
+
#Be compiler agnostic and initially support both GCC and LLVM. One of the biggest weaknesses of the earlier MILEPOST project was that it became inextricably tied to one particular compiler, GCC, and indeed to a specific release, so making it near impossible to maintain or to be put into general use.
 
#Deliver a working system! This is government funded industrial research, but it is focussed on taking existing knowledge from projects such as MILEPOST and putting it to work in very much a practical way.
 
#Deliver a working system! This is government funded industrial research, but it is focussed on taking existing knowledge from projects such as MILEPOST and putting it to work in very much a practical way.
  
== People ==
+
For more information see the [[MAGEEC|wiki]].
 
 
There is a small core of people working on MAGEEC throughout the next 18 months:
 
 
 
*Dr Jeremy Bennett from Embecosm is the overall project manager
 
*Dr Simon Hollis is the project lead for Bristol University
 
*Simon Cook is the lead engineer for the project and will be writing most of the code
 
*Dr Kerstin Eder from Bristol University is the project's machine learning expert
 
*Dr Oliver Ray from Bristol University is the project's relational machine learning expert
 
*Andrew Back is community manager
 
 
 
However, MAGEEC provides the opportunity for many others to participate, and current collaborators include:
 
 
 
*Munaaf Ghumran, an undergraduate at Bristol, who is working on the initial machine learning framework during Summer 2013
 
*Ashley Whetter, also an undergraduate at Bristol, who is bringing up the energy measurement hardware infrastructure
 
*Joern Rennecke, Embecosm's principal GNU tool chain engineer, who will be developing optimization passes specifically intended to improve energy efficiency
 
*James Pallister, PhD student at Bristol and HiPEAC intern at Embecosm, who developed the original energy measurement infrastructure
 
 
 
If you'd like to contribute please get in touch via the mailing list or IRC.
 
 
 
== How will the MAGEEC software work? ==
 
 
 
We are still in the early stages of design work — Simon Cook will write more about this in future posts. However, one very early design decision is reflected by the importance of independence from any one compiler, and so MAGEEC will always work through a compiler's plug-in interface. This plug-in interface will be required to supply details of the features of programs being compiled and to be capable of controlling the compiler's pass manager.
 
 
 
Similarly we have taken an early decision to provide a clean interface to the machine learning system. For training this will supply data on program features and passes used with the associated performance metric (in this case energy consumption). In use it will take a set of program features and return information about the optimization passes to use.  
 
 
 
== Measuring energy consumption ==
 
  
Measuring actual energy consumption is a very important part of the project. At its simplest this involves putting a series resistor (typically 0.1Ω) in the power line and measuring the voltage drop across it. But we do need to do this at high frequency and to collect the data automatically.
+
== Licensing ==
  
Our latest energy measurement board can take 6 million samples per second, getting us close to being able to measure the energy consumed by individual instructions.
+
All hardware designs, software source code and data sets produced as part of this project will be provided under open licensing.
  
== Support ==
+
Our policy is to use reciprocal, a.k.a. "[http://en.wikipedia.org/wiki/Copyleft copyleft]", licensing to ensure the continued freedom of the work.
  
MAGEEC is supported by the <[https://www.innovateuk.org/ Technology Strategy Board] (TSB) under its [http://webarchive.nationalarchives.gov.uk/20130221185318/www.innovateuk.org/content/competition/energy-efficient-computing.ashx Energy Efficient Computing Initiative].
+
== Resources ==
  
Running for 18 months from June 2013, it is a joint project between the open source compiler and silicon chip modeling company, [http://www.embecosm.com/ Embecosm], and Bristol University’s [http://www.cs.bris.ac.uk/ Department of Computer Science].
+
As with many open source projects we have our own [[MAGEEC|wiki]], [http://mageec.org/cgi-bin/mailman/listinfo/mageec mailing lists] and [[MAGEEC#IRC|IRC channel]], and over the coming months we'll be working to engage with the wider community.

Latest revision as of 13:28, 22 August 2013

Welcome to MAGEEC — the MAchine Guided Energy Efficient Compiler framework.

MAGEEC is an open source project which combines work on compilation options which save energy with work on machine learning, to create a compiler framework that is capable of generating code that has improved energy efficiency.

Goals

We've set ourselves four goals.

  1. Optimize for energy. Existing compilers optimize either to minimize execution time, or code size. This project is about generating code which when executed will used as little energy as possible.
  2. Use physical measurement of energy usage, not models. One of the problems with past projects has been using models of the amount of energy used, but these are at best accurate only to 10%, whereas individual compiler optimizations can have far smaller effects. But more importantly such models have implicit assumptions about how the processor works on which their models are based, and any compiler using such models would optimize for these assumptions, not for the actual processor.
  3. Be compiler agnostic and initially support both GCC and LLVM. One of the biggest weaknesses of the earlier MILEPOST project was that it became inextricably tied to one particular compiler, GCC, and indeed to a specific release, so making it near impossible to maintain or to be put into general use.
  4. Deliver a working system! This is government funded industrial research, but it is focussed on taking existing knowledge from projects such as MILEPOST and putting it to work in very much a practical way.

For more information see the wiki.

Licensing

All hardware designs, software source code and data sets produced as part of this project will be provided under open licensing.

Our policy is to use reciprocal, a.k.a. "copyleft", licensing to ensure the continued freedom of the work.

Resources

As with many open source projects we have our own wiki, mailing lists and IRC channel, and over the coming months we'll be working to engage with the wider community.