Re: [MirageOS-devel] Whole Program Optimization in Mirage

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 30 Jun 2014, at 11:29, Malcolm Matalka <mmatalka@xxxxxxxxx> wrote:

> I've seen it mentioned a few times that Mirage does WPO.  Is there
> documentation on what exactly this means?  I am under the impression
> that the ocaml compiler does not do whole program optimisation.
> 

I tend not to call it WPO when speaking, but 'whole OS optimisation'
instead (although slips of the tongue have no doubt happened).  There
are a few different forms this optimisation could take in Mirage:

- cross-module inlining: as Goswin points out, the compiler already does
  this optimisation and it's helpful that a lot of configuration code is
  also just OCaml code, thus allowing the compiler to propagate constants
  into library code.  We haven't done a comprehensive analysis of the
  effectiveness of this for larger applications (e.g. mirage-www).  Pierre
  Chambart has an -flambda branch that is aimed at OCaml 4.03 which 
  significantly improves the amount of inlining the compiler does.
  Mirage should be an excellent way of stress-testing it and also looking
  at detailed CMM dumps to check that the optimisation is effective.

- staged programming: the Mirage tool evaluates a config.ml, and outputs
  an OCaml main.ml which performs the functor applications into a concrete
  module.  This gives the compiler more static knowledge than if we used
  first-class modules.  Again, we don't have much defunctorisation in the
  compiler right now, but Pierre's -flambda branch will help a lot (no
  pressure, Pierre :-)

- data representation: the gold standard for WPO is MLTon's transformations
  on the representation layout of data structures by monomorphising all
  types, eliminating separate compilation and doing optimizations on the
  resulting graphs.  Thomas and I experimented with this approach with a 
  poor man's WPO in OCaml -- do a source transform by concatenating the
  entire unikernel source into a single ML file, and compile that.  We
  never extended it to actually change memory layout of values, so that's
  still an open (and interesting) problem to anyone interested.  We've
  considered exposing the compile-time representation of every type as a
  Ctypes GADT, as a first step in this direction.

- Syntax transformations: something that doesn't really count as WPO --
  but is still applied across all modules -- are camlp4 extensions that
  do local transformations on the AST.  The main two used are cstruct and
  lwt in Mirage libraries.  A combination of a macro system and staged
  programming in OCaml would make it much easier to evaluate static
  knowledge at build-time (particularly for configuration directives).

-anil
  

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel