Difference between revisions of "Meeting 22-07-2013"
From MAGEEC
(Format Meeting Minutes) |
|||
| Line 1: | Line 1: | ||
| − | + | ==== Present ==== | |
| + | [[JB]], [[SC]], [[MG]], [[AW]], [[JP]], [[SH]], [[KE]], [[OR]] | ||
| − | + | == Hardware Energy Monitoring Report (Ashley) == | |
| − | |||
| − | |||
| − | |||
* Slow progress due to needing to get the hardware working | * Slow progress due to needing to get the hardware working | ||
| Line 13: | Line 11: | ||
** Capable but the level of additional soldering required, lack of voltage divider and need for external resistors makes it less easy to use for V2. | ** Capable but the level of additional soldering required, lack of voltage divider and need for external resistors makes it less easy to use for V2. | ||
* Benchmarks working and verification of their correctness being worked on. | * Benchmarks working and verification of their correctness being worked on. | ||
| − | ** TODO: Now a priority to push on internal verification code to the tests. | + | ** '''TODO''': Now a priority to push on internal verification code to the tests. |
*** e.g. compare outputs to pre-computed correct and return result. | *** e.g. compare outputs to pre-computed correct and return result. | ||
* When running the benchmarks, we should apply techniques such as <tt>extern</tt>s or <tt>volatile</tt>s that can store e.g. the final result. | * When running the benchmarks, we should apply techniques such as <tt>extern</tt>s or <tt>volatile</tt>s that can store e.g. the final result. | ||
** Dijkstra program not working, others are. | ** Dijkstra program not working, others are. | ||
| − | * TODO: Get the benchmarks (BEEBS / BBS) work for last year out there with more oomph (webs, publicity, workshops...) | + | * '''TODO''': Get the benchmarks (BEEBS / BBS) work for last year out there with more oomph (webs, publicity, workshops...) |
* James 13th 14th September will give a talk at OSHCAMP on energy monitoring board design. | * James 13th 14th September will give a talk at OSHCAMP on energy monitoring board design. | ||
| − | * TODO: Run code that straddles flash banks and runs on flash to see differences in energy → feeds well into 'discovery' phase of ML. | + | * '''TODO''': Run code that straddles flash banks and runs on flash to see differences in energy → feeds well into 'discovery' phase of ML. |
| − | + | ==MAGEEC Blog posts== | |
* Weekly (ish) blogs, from rotating members of the team. | * Weekly (ish) blogs, from rotating members of the team. | ||
| − | * TODO: 22/07/2013: Jeremy this week for an intro | + | * '''TODO''': 22/07/2013: Jeremy this week for an intro |
| − | * TODO: 29/07/2013: Ashley next week for intro to energy monitoring hardware. | + | * '''TODO''': 29/07/2013: Ashley next week for intro to energy monitoring hardware. |
** Ensure the draft is saved. | ** Ensure the draft is saved. | ||
** Andrew will perform the final publishing | ** Andrew will perform the final publishing | ||
| − | * TODO: 05/07/2013: Moon, intro to his work. | + | * '''TODO''': 05/07/2013: Moon, intro to his work. |
| − | + | ==Compiler Framework== | |
* No new update on implementation, due to attending GCC meeting etc. | * No new update on implementation, due to attending GCC meeting etc. | ||
| Line 40: | Line 38: | ||
*** Can some examples of data be generated so that it can be represented for ML learning. | *** Can some examples of data be generated so that it can be represented for ML learning. | ||
| − | + | ==MILEPOST Approach== | |
* <nowiki>Normalised feature vector 0<= 1 using the number of instructions as the divider.</nowiki> | * <nowiki>Normalised feature vector 0<= 1 using the number of instructions as the divider.</nowiki> | ||
| Line 49: | Line 47: | ||
** Data set available by end of week. | ** Data set available by end of week. | ||
** Performance as metric. | ** Performance as metric. | ||
| − | * <nowiki> | + | * '''TODO''': <nowiki>Paper on James' previous work? Of 130 flags in GCC only 13 make a difference [in our scenarios]. We want to understand why.</nowiki> |
* Consider systematic (FFD) vs exhaustive vs random selection and their effectiveness. | * Consider systematic (FFD) vs exhaustive vs random selection and their effectiveness. | ||
** Part of the MSc work will address this. | ** Part of the MSc work will address this. | ||
| Line 58: | Line 56: | ||
* There are techniques for looking at flag dependencies, but they need further investigation. | * There are techniques for looking at flag dependencies, but they need further investigation. | ||
| − | + | ==Framework representation for enabling ''later'' advanced ML work== | |
* Reference SC's previous Overall Design slide. | * Reference SC's previous Overall Design slide. | ||
| Line 72: | Line 70: | ||
* How to support backtracking prediction. | * How to support backtracking prediction. | ||
** Unlikely in GCC due to global state. | ** Unlikely in GCC due to global state. | ||
| − | * TODO: SC to produce a draft spec by 31/07/2013 | + | * '''TODO''': [[SC]] to produce a draft spec by 31/07/2013 |
| − | + | ==Planning== | |
* Hardware design and build completed on time. | * Hardware design and build completed on time. | ||
* No new streams of work coming online. | * No new streams of work coming online. | ||
* All else proceeding OK. | * All else proceeding OK. | ||
| − | * TODO: By 29/07/2013: Action the kit buying | + | * '''TODO''': By 29/07/2013: Action the kit buying |
| + | |||
| + | ==Actions carried forward from previous meeting:== | ||
| − | + | * [[SH]]: Apply for BlueCrystal Accounts for all | |
| + | * [[KIE]]: To decide on whether for two PCs with 32GB was one PC with two cores and much more RAM | ||
| − | + | [[Category:Meetings]] | |
| − | |||
Latest revision as of 10:20, 23 July 2013
Contents
Present
JB, SC, MG, AW, JP, SH, KE, OR
Hardware Energy Monitoring Report (Ashley)
- Slow progress due to needing to get the hardware working
- Software installation / OS issues
- Moved to use a previous version (V2) energy-monitor boards, since they are more suitable
- Problems using V3 to measure external device energy consumptions
- Capable but the level of additional soldering required, lack of voltage divider and need for external resistors makes it less easy to use for V2.
- Benchmarks working and verification of their correctness being worked on.
- TODO: Now a priority to push on internal verification code to the tests.
- e.g. compare outputs to pre-computed correct and return result.
- TODO: Now a priority to push on internal verification code to the tests.
- When running the benchmarks, we should apply techniques such as externs or volatiles that can store e.g. the final result.
- Dijkstra program not working, others are.
- TODO: Get the benchmarks (BEEBS / BBS) work for last year out there with more oomph (webs, publicity, workshops...)
- James 13th 14th September will give a talk at OSHCAMP on energy monitoring board design.
- TODO: Run code that straddles flash banks and runs on flash to see differences in energy → feeds well into 'discovery' phase of ML.
MAGEEC Blog posts
- Weekly (ish) blogs, from rotating members of the team.
- TODO: 22/07/2013: Jeremy this week for an intro
- TODO: 29/07/2013: Ashley next week for intro to energy monitoring hardware.
- Ensure the draft is saved.
- Andrew will perform the final publishing
- TODO: 05/07/2013: Moon, intro to his work.
Compiler Framework
- No new update on implementation, due to attending GCC meeting etc.
- GCC meeting feedback is that HPC community (inc. LLL) very interested into learning more about low power.
- Looked at the research questions posted from UoB discussion on the wiki.
- Profile-directed optimisation is very powerful, perhaps most powerful
- Joern to be quizzed by James about the kinds of profile data that comes out, since it can impact the machine learning.
- Can some examples of data be generated so that it can be represented for ML learning.
MILEPOST Approach
- Normalised feature vector 0<= 1 using the number of instructions as the divider.
- Ran 1000 random on/off flags, then kept the top 5% of previously trained data.
- Question on whether or not the flags are orthogonal.
- MSc student is addressing:
- Taking James' flags of significance and isolating these and exhaustively
- Data set available by end of week.
- Performance as metric.
- TODO: Paper on James' previous work? Of 130 flags in GCC only 13 make a difference [in our scenarios]. We want to understand why.
- Consider systematic (FFD) vs exhaustive vs random selection and their effectiveness.
- Part of the MSc work will address this.
- Moon investigating which of the MILEPOST vectors are and are not useful. Needs a large data set of 150+ applications to check them.
- Work on WCET to extract additional programs to help with this.
- Look (longer term) at HPC space to augment these.
- MILEPOST Approach Summary: Run with 1000 flags randomly. Having discarded invalid flags, take top 100 good ones and run accumulating stats showing which are in best sets between iterations
- There are techniques for looking at flag dependencies, but they need further investigation.
Framework representation for enabling later advanced ML work
- Reference SC's previous Overall Design slide.
- Oliver outlined the “credit assignment” problem for ML to infer what causes improvement.
- gen_features() just gives a list of passes that will be run.
- Mapping of passes to flags needed.
- A lot of debate about whether to use a feature vector, IR or source code for selecting the relevant features for ML.
- Main takeaway – we need to be able to cope with changes in the features that are relevant as our knowledge of this evolves.
- Feature info passing should be generic (enough to be able send IR, if necessary).
- Should plan for plugin re-write next year if necessary to aid this.
- How to support backtracking prediction.
- Unlikely in GCC due to global state.
- TODO: SC to produce a draft spec by 31/07/2013
Planning
- Hardware design and build completed on time.
- No new streams of work coming online.
- All else proceeding OK.
- TODO: By 29/07/2013: Action the kit buying
