Meeting 09-10-2013

MAGEEC Meeting 09/10/2013 Present JB, SJH, AB, KIE, Hayden Fields, AW, MG, Craig Blackmore

Planning and management

• Current progress slightly behind schedule
  • Simon C will increase hours in October
  • Joern will begin work soon

Exploitation

• Power measurement board has some commercial interest from Wuthering Bytes
  • Paul Tanner
  • Ken Boak
  • We should produce a batch for sale/donation to interested parties

Benchmark sources (see also note on Moon's discussion)

• Could ask the community to run BEEBS on multiple platforms
• Could ask community to supply applications as benchmarks
• LLVM regression test suite
  • Coreutils have some library depencies and some are small
    • Suggestion to select those that are usable and large enough
  • LLVM regression tests
• GDB regression tests
• Initially, we need a large set of test programs for a single platform, then extend.
• Dhrystone
• osadl.org
• nqueens type
• From post: https://mailman.cs.umd.edu/pipermail/otter-dev/2011-January/000521.html

Coreutils (KLEE)

Busybox
Minix utilities
HiStar
SQLite (Execution Synthesis)
ghttpd
HawkNL
SGLIB (CUTE)
vim (Hybrid concolic testing)
oSIP (DART)

FOSDEM

• Devroom proposal has been accepted
  • Nominally 9am-4pm on Sunday
  • May be a tiered lecture room
• Should the day be broken into themed blocked
  • e.g. Energy measurement
  • Code optimisation
  • Transparency
  • …
• Workshop timing after lunch
• Proposal for technical talk is still under consideration (Dec decision)
• TSB contribution to recognise UK gov + Open source and how to support them.
• We should issue a call for contributions
  • Looking for talks and hands-on demonstrations
  • Esp. check if Prof Luca Benini's group is interested in contributing
• Call contents:
  • Lightning talks
  • Suggested parts of workshops
  • Presentations
  • Demonstrations
  • Lightning talks
  • Out through at least: HiPEAC, OSHUG, BCSOSSIG, TSB, EACO, research community
• Might we want a MAGEEC table on Saturday (in corridors) to pull interest into Sunday
• Energy-measurement board workshops (need boards + numbers cap + iterations)
  • Could be AVR/Shrimping before the day, with kits provided beforehand
  • Could be ARM+Energy measurement boards hackathon on the day
• Competition element
  • KIE suggests delaying to next year
  • SJH thinks we may be able to do it on the day
  • JB thinks that it could be beforehand or not easy to do this year
  • AB wonders if it could be online
  • Majority view seems to be to delay
• Lightning talks?
• Birds-of-a-feather session
  • Shall we encourage other people we know to attend
  • European 'experts' in energy efficiency expected
• BEEBS
  • Introduction + a 'bring along your code' session where we can feed more applications into the MAGEEC project.
  • Could we run a re-engineering for optimisation game session
• EACOF demo
  • Hayden has a 10-15 min presentation
  • Linux + OSX support
    • Could possibly be packaged up for a workshop
      • Jeremy has concerns over the work involved for this
        • Perhaps it should be a demo + one-to-one 'guru' session for you to install on your own machine.
  • SAC paper in the works
    

ACTION: AB: Draft call for participation this week for dissemination next week. Arrange a phone call to discuss the draft.

ML Discussion (Moon)

• J48 strongly indicated as best ML approach going forward
• Moon will continue with work as project, and LLVM target
• Need to extend test suites (see benchmarks section)
• Action: Moon to make a blog post on the literature review

BEEBS

• Do we need a notion of scaling factors for BEEBS on smaller/larger platforms.
  • Could drive towards energy-proportional computing
• Do we need to fix the implementation for a given architecture in terms of data sizes etc.
• Extensions: Do we want to re-write BEEBS for platforms to remove usage of libraries (C standard libraries)
  • JB: Could be a lot of work for nothing, but libraries should be compiled with same options as the BEEBS code.
    • Official libraries probably been optimised for the architecture.
  • KIE: Could require the user to know about the external library. e.g. -dIncludeExternalLibrary, to make them aware.
    • Or provide both standalone and libraried code.
  • SH: What difference in energy from running with included libraries vs all in the source file (i.e. can global analysis do better with all of the code). JP to experiment on this with BEEBS.
  • Consensus: need both at this stage.
  • Action: JP to explore.

Database

• Oliver gave a very useful presentation on potential database schemas
• Selected Approach 4, with tweak so that RH table is keyed on hash of option sequences. This allows fast checking of existence of a flag set.
  • Weak hash OK, since checking of collision is low cost.Action: Simon C to review Oliver's presentation and schema and suggest how to integrate into the framework.

Student projects (Craig)

• Interests in benchmark collation and evaluation
  • Why does X have the impact is does
  • How could an architecture/compiler be optimised based on what we find out
• Declarative learning
  • KIE suggests follow on from Bin Tao's work
    • SJH suggests moving to Beaglebone to simultaneously gather performance and energy
• SJH: Energy modelling
  • Reverse build from MAGEEC data and James-type analysis of traces.
  • ARM energy building
  • JB: OpenRISC, combined with WAATCH is a one way
• KIE: ENTRA work pushing up ISA model to IR for multi-threaded scheduling for optimality