Planning Exupery 0.13

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Planning Exupery 0.13

Bryce Kampjes

My current plan for 0.13 is:
  * Get background compiler to ignore methods that failed to compile
  * Don't flush the code cache on every class change
  * Fix more bugs
  * Add some instrumentation to get quantitative information on time
    spent compiling and the percentage of time spent in compiled code.

The goal is to make the background compiler practical. It will still
be limited due to missing features slowing down compiled code and slow
compile times. A test would be to run the background compiler until
Exupery was compiled then to start playing with tinyBenchmarks and to
see the improvement as it compiles the methods and inlines the
primitives.

Currently the background compiler doesn't avoid methods that have
failed to compile once. This is a problem as the compilation queue
could get full of methods that don't compile blocking compilation of
methods that do compile.

Flushing the code cache on every class change is overkill. It also
reduces the value of some of the acceptance testing as it can't
effectively test compiling tests that change classes and several do.

It would be nice if Exupery reported the percentage of time spent in
compiled code to gauge how well the background compiler was doing. I
can measure this using oprofile but not in Squeak. It would also be
nice if Exupery recorded how long a method took to compile to gauge
how much of a problem compilation speed currently is. It would be nice
if Exupery recorded why methods failed to compile so it was easy to
figure out how important adding the remaining missing features is.


The other possibility for 0.13 would be to optimise compilation time.
There are a few methods that take minutes to compile due to known
performance bugs in the register allocator. Increasing the speed of
the compiler will both make compilation more practical and make it
cheaper to compile more code in tests.

The third major thing required before a 1.0 would be to implement
cascades and a few more bytecodes. This should allow Exupery to
optimise more code successfully. This is aiming to optimise run time
performance. I'm not considering this for 0.13 but is needed before
1.0.

Bryce
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

Re: Planning Exupery 0.13

Igor Stasenko
Hi Bryce,
can you explain, please, what you mean is 'failed to compile'?
What blocking Exupery to compile them? Primitives, special bytecodes?

On 26/10/2007, [hidden email] <[hidden email]> wrote:

>
> My current plan for 0.13 is:
>   * Get background compiler to ignore methods that failed to compile
>   * Don't flush the code cache on every class change
>   * Fix more bugs
>   * Add some instrumentation to get quantitative information on time
>     spent compiling and the percentage of time spent in compiled code.
>
> The goal is to make the background compiler practical. It will still
> be limited due to missing features slowing down compiled code and slow
> compile times. A test would be to run the background compiler until
> Exupery was compiled then to start playing with tinyBenchmarks and to
> see the improvement as it compiles the methods and inlines the
> primitives.
>
> Currently the background compiler doesn't avoid methods that have
> failed to compile once. This is a problem as the compilation queue
> could get full of methods that don't compile blocking compilation of
> methods that do compile.
>
> Flushing the code cache on every class change is overkill. It also
> reduces the value of some of the acceptance testing as it can't
> effectively test compiling tests that change classes and several do.
>
> It would be nice if Exupery reported the percentage of time spent in
> compiled code to gauge how well the background compiler was doing. I
> can measure this using oprofile but not in Squeak. It would also be
> nice if Exupery recorded how long a method took to compile to gauge
> how much of a problem compilation speed currently is. It would be nice
> if Exupery recorded why methods failed to compile so it was easy to
> figure out how important adding the remaining missing features is.
>
>
> The other possibility for 0.13 would be to optimise compilation time.
> There are a few methods that take minutes to compile due to known
> performance bugs in the register allocator. Increasing the speed of
> the compiler will both make compilation more practical and make it
> cheaper to compile more code in tests.
>
> The third major thing required before a 1.0 would be to implement
> cascades and a few more bytecodes. This should allow Exupery to
> optimise more code successfully. This is aiming to optimise run time
> performance. I'm not considering this for 0.13 but is needed before
> 1.0.
>
> Bryce
> _______________________________________________
> Exupery mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
>


--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

Re: Planning Exupery 0.13

Bryce Kampjes
Igor Stasenko writes:
 > Hi Bryce,
 > can you explain, please, what you mean is 'failed to compile'?
 > What blocking Exupery to compile them? Primitives, special bytecodes?

The two main causes are missing primitives and bytecodes. The main
bytecode missing is the dup bytecode used to implement cascades. There
isn't a strong case for compiling most primitives as they're already
optimised by the C compiler. There are a few frequently called
primitives that provide oportunity to optimise such as the #at:
primitive.

It's only when compiling the method which contains the primitive that
a missing primitive will cause Exupery to fail to compile. It deals
gracefully with a failure to inline a primitive which is much more
common.

Another problem with the current code to drive the background compiler
is the profiler may queue a method to compile that's already in the
queue. This is wasteful but doesn't seem to happen a lot.

Bryce
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery