Musings

These are random notes about the team and our scope. Most of these are wider than our actual scope and plans.

Why do we do things?

  • Make mobile more responsive, interactive, power efficient

How can we do this?

  • Good base level tools
  • Tools that generate faster code (compiler)
  • Faster core infrastructure (libraries)
  • Making multicore usable
  • Making all of the SoC usable
  • Tools that make hard performance problems easier to diagnose
  • Everything available early (public, backports)
  • Everything easy to pick up and use (binaries, documentation, howtos, findable)

What platforms?

  • Android
  • GLIBC Linux

What attributes?

  • Product (hardware specific customisation) vs distribution (good defaults, runtime customisation)
  • Process level vs system level (interaction causing faults)
  • Early faults vs long term faults (long term leaks, missing constraints, leaks)
  • Development vs production (tools usable during production test/field)
  • Cross vs native

Questions:

  • Windows as a development host?
  • Mac OS X as a development host?

Some things are a given as part of how we do things, like:

  • Products are correct
  • Tested
  • Upstream, preferably upstreamed first
  • Released as source
  • Often released as a binary
  • Easy to find
  • Easy to try

Base level tools

What must we have?

  • Compiler: GCC
  • Debugger: GDB
  • Profiling: perf (gperf is a given)
  • Trace: PENDING SystemTap?

  • Coverage: PENDING gcov
  • Other PENDING: valgrind

There's a cost to keeping up, maintaining, and releasing these primary products.

Tools

Use a mix of bottom up and top down. Bottom up are tools that allow others to build larger things, like having a good LLVM for others to make Renderscript. Top down are use cases giving tools, such as wanting to use all of the SoC needing inter-core communication.

Tools include:

Compiler Languages Debugging Profiling Trace Libraries Multicore Emulation Production
GCC Perl GDB perf SystemTap/DTRACE libc Atomics Emulator Obsufication?
LLVM Python LLDB Cache profiler System trace? String routines OpenMP Simulator? Crash reporter?
Java Ruby valgrind Heap profiler Render trace Renderscript gcov
Dalvik OpenOCD Visualisation MPI

The following are epic, have many aspects, and would continue to be developed. Others would need a one-off effort.

Compiler

Languages

Debugging

Profiling

Trace

Libraries

Multicore

Emulation

Production

GCC

Perl

GDB

perf

SystemTap/DTRACE

libc

Atomics

Emulator

Obsufication?

LLVM

Python

LLDB

Cache profiler

System trace

String routines

OpenMP

Simulator?

Crash reporter?

Java

Ruby

valgrind

Heap profiler

Render trace

Renderscript

gcov

Dalvik

OpenOCD

Visualisation

MPI

Known areas are:

  • GCC: vectoriser
  • LLVM: speed, hard float, vectoriser
  • Renderscript: performance, debugging, profiling, tracing, host development
  • GDB: Android integration
  • Valgrind: cache modelling
  • GLIBC: IFUNC use, A9/A15/NEON specialisation
  • String routines: str*, landing everywhere

Should be worthwhile but need checking:

  • GCC: PGO, LTO, OpenMP, STM
  • LLVM: correctness
  • GDB: non-stop debugging
  • Dalvik: performance, cross-language debug, perf integration, tracepoints
  • valgrind: all tools that need a call stack, thread debugger ARM support

Unknown areas are:

Out of scope

Explicitly out of scope are:

  • Browser improvements, except as found through using browsers as a benchmark
  • Size optimisations

Randoms

Unsorted:

  • Thread timing
  • Security?
  • Static analysis?
  • Dr. Memory: Memory Debugger for Windows and Linux
  • Field support

To check:

  • GCC bugzilla
  • Mudflap
  • OpenMP
  • MPI
  • STM on ARM
  • GCC wiki recent edits
  • futex
  • GDB features
  • Libraries which have x86 assembly versions
  • Kernel driven trace/probe features
  • OMAP4 TRM
  • O'Reilly books
  • Apple specific
  • Software Tools User Group
  • JavaScript

  • Multimedia in this list?
  • Graphics?

MichaelHope/Musings (last modified 2012-07-19 04:25:08)