Meeting 22-07-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.
  • 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

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