Difference between revisions of "Meeting 21 July 2014"

From MAGEEC
Jump to: navigation, search
(Corrected meaning of BEEBS acronymn)
 
Line 52: Line 52:
  
 
* CMSIS-DSP tests
 
* CMSIS-DSP tests
* BEEBS name across repository → “Bristol/Embecosm Energy Benchmark Suite”
+
* BEEBS name across repository → “Bristol/Embecosm Embedded Benchmark Suite”
 
* ARM CMSIS Maths + OS functions to add
 
* ARM CMSIS Maths + OS functions to add
 
* Push on self-validation with conditional compilation
 
* Push on self-validation with conditional compilation

Latest revision as of 08:02, 4 August 2014

MAGEEC Meeting 21/07/2014 - Lymington


Review of action points from last time


Greg


  • Script to generate PCA configurations
  • 700 runs on 10 programs from BEEBS: training ~15s
  • GC Q: Is the training exponential in programs
  • Communal database needs SC input
  • Auto-generation of benchmarks.

George

  • DejaGnu framework
  • ARM tools
  • Cuttlefishes made. Programmers needed.
  • Plackett-Burnham
    • Aliasing: not a high prority
    • Assuming factors independent
    • Aim it to find factors that actually matter
    • FFD on factors in cascaded manner to make number of tests tractable. Estimate ~2000 tests taking ~5h in parallel on 6 boards.

Stoil

  • SG: Categorisation of BEEBS V2.0 not started

Generic issues

  • [AB+JP+GF] Agreed method to compile in pseudo-random data sets in a generic manner
  • GIMPL SSA headers missing from Ubuntu => MAGEEC build
  • [JP+SG] Energy measurement code needs to be compilable.
  • [SH] IDD header on measurement boards needs to be taller.

BEEBS

  • Branching

Calibration of hardware

  • From tech node analysis, perhaps 2% total variation in system energy (0.4% static power; 1-2% dynamic power) with temperature variation.
  • Board-to-board variation needs more analysis.
    • [GC+JP] Measure and analyse the variation
  • [JP] Actually measure board-to-board variation.
  • We may need multiple runs of energy measurements across multiple boards to smooth the probability distribution.

BEEBS

  • CMSIS-DSP tests
  • BEEBS name across repository → “Bristol/Embecosm Embedded Benchmark Suite”
  • ARM CMSIS Maths + OS functions to add
  • Push on self-validation with conditional compilation
    • Can turn off for code size analysis
    • Validation after the measurement STOP trigger
  • AB 'gatekeeper' of gitbub repository. Push requests to him.

Case studies

  • ARM – built out of CMSIS DSP functions
  • CMSIS-RTOS – Keil RTX

Optimisations on a per-function basis

  • Some kind of profiling to show the per-function distribution of execution costs is needed
    •  ? Is -O2 a good basis for counting instructions
  • We may need to assume that time and energy are proportional for this.

Work going forward


Stoil

  • Simulation of BEEBS for categorisation
    • AVR simulavr simulator → trace
    • qemu for ARM for each instruction. Also CGEN & Keil.
    • [2 week challenge] Analyse different evaluations of the BEEBS at three different levels, following this question:
  •  ??? Do we categorise based on input program (generic) or instruction output (architecture-specific). What does the feature vector (intermediate level) expose from these for the generic level.
    • SC will help from 28/07/2014
    • gprof for dynamic execution count
    • Raspberry Pi may be a good compilation platform.

George

    • [2 weeks] AVR tests to do with new hardware

Greg

  • Start moving on PCA of BEEBS.
    • Coordinate with Craig.

Oliver

  • Short blog post

Simon

  • Boards quotations
    • 100, 250, (500), 1000 volumes
    • Lead times

James

  • Calibration tests on Embecosm boards