Profiling and Optimization of AmbientTalk

Tom Van Cutsem, PROG
Christophe Scholliers, PROG

The goal of this apprenticeship proposal is to perform a thorough profiling and optimization of the AmbientTalk programming language. AmbientTalk is a dynamically typed language in the spirit of Ruby and Python, but specifically targeted at writing distributed applications in mobile (ad hoc) networks.

A proof-of-concept interpreter for AmbientTalk exists (written in Java), but it has virtually no optimizations and is therefore not competitive with respect to similar languages like Jython and JRuby.

The goal of this apprenticeship project is to:

1. benchmark AmbientTalk according to the Programming Languages shootout benchmarks. We require an implementation of at least 5 different benchmarks in AmbientTalk. This allows us to compare AmbientTalk's performance with similar languages.
2. profile the AmbientTalk interpreter, to get an overview of the 'hot spots' that need optimization.
3. optimize the 'hot spots' of the interpreter by means of any applicable technique (e.g. caching, compilation to bytecode, etc.)

More detail about each of these steps is provided below:

Step 1: Benchmarking

1. Implement the language shootout benchmarks in AmbientTalk.
2. Identify useful “competitor” languages (likely competitors are JRuby, Jython and Groovy).
3. Implement little “micro-benchmarks” that test the runtime of e.g. a method call, an assignment, a variable lookup in all languages under study.
4. Install competitors and AmbientTalk on the same test machine.
5. Run the benchmarks on all languages (requires reading about how to correctly measure benchmarks, taking into account startup time, JIT behavior, etc.)
6. Process results (requires some basic knowledge about statistics)

Step 2: Profiling

1. Identify useful tools (Java profilers, Eclipse Plug-ins) that allow us to profile the AmbientTalk interpreter.
2. Profile the interpreter using those tools.
3. Identify “hot-spots” (= repeatedly invoked code, meaning that optimizing this code pays off the most) and “bottlenecks” (those pieces of code that introduce the most performance penalties)

Step 3: Optimizing (not all of the below optimizations need to be applied, we will have to identify the most relevant ones based on the results of step 2) Possible optimizations include:

1. Remove as much reflection as possible from the interpreter code (by means of on-the-fly bytecode generation)
2. Implement a (bytecode)-compiler for AmbientTalk's ASTs.
3. Implement Polymorphic Inline Caches.
4. Implement lexical addressing.
5. Replace 1 thread per actor by a thread pool.
6. Measure the effects of your optimizations using the setup of Step 1.

Instead of a bytecode interpreter, see the following set of blog posts on how to speed up an interpreter written in a language like Java/C#:

• http://funcall.blogspot.com/2008/09/threaded-interpreter.html
• http://funcall.blogspot.com/2008/09/s-code.html
• http://funcall.blogspot.com/2008/09/now-it-starts-getting-interesting.html
• http://funcall.blogspot.com/2008/09/in-from-generalized-stack-inspection.html

Steps 1 and 2 will be performed during an apprenticeship at the PROG lab. Step 3 can be performed in the context of a Masters Thesis, also at the PROG lab and immediately following the apprenticeship period.

For more information, contact us (tvcutsem at vub…) or come and visit us on Friday, May 8th in the afternoon at the PROG lab.