develooper Front page | perl.perl6.language | Postings from July 2005

Optimization pipeline

Thread Next
From:
Yuval Kogman
Date:
July 14, 2005 17:05
Subject:
Optimization pipeline
Message ID:
20050715000522.GC11028@woobling.org
I'd like to document the optimization pipeline thing I brought up in
the hackathon...

The intent is to plan how to balance throughput with responsiveness
for a language that has such a broad range of dynamic to static
typing as Perl 6 will is.

With such behavior the amount of optimization you can do is
limitless, but the amount you actually want to do varies...

The runtime engine, environment variables, or whatever control
this, it doesn't matter what the interface is, but the concept is:

	- optimizers stack on top of each other
	- the output of each one is executable
	- optimizers work in a coroutine, and are preemptable
	- optimizers are small
	- optimizers operate with a certain section of code in mind

Basically you transform the PIL structures, or the byte code, or the
resulting machine code if any, as it's going to be executed. This is
old news.

Optimizers get time slices to operate on code as it is needed. They
get small portions - on the first run only simple optimizations are
expected to actually finish.

However, as code is re-executed, a proportion of the time it took to
run it is spent on optimizing it, so that if code is rerun often
eventually the optimizers will finish optimizing that bit of code.

The goal is to achieve good responsiveness for tight edit/debug
cycles, but achieve good performance for mod_perl like apps.

With really crazy optimizations in a coupled compile+run environment
(where parrot and the perl 6 compiler can talk to each other and
rewrite code for each other) slow but busy code will eventually have
enough time spent on it so that it's fast enough, but results are
still available ASAP.

The scenarios in which this is pleasing is high uptime, long running
applications, and short scripts.

Of course, the proportion of time, size of data structures, various
policies should all be under control, but as a guiding principal I
think that a JIT pipeline approach is the most balanced.

Nothing should stop anyone from disabling everything, or
pre-optimizing everything during compilation - it's just that the
default trigger should the actual execution of chunks of code.

-- 
 ()  Yuval Kogman <nothingmuch@woobling.org> 0xEBD27418  perl hacker &
 /\  kung foo master: /me sushi-spin-kicks : neeyah!!!!!!!!!!!!!!!!!!!!


Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About