Where to next with Exupery?

Bryce Kampjes bryce at kampjes.demon.co.uk
Sat May 14 13:38:08 UTC 2005


What is needed to encourage wide usage of Exupery? I'm just finishing
up the 0.06 release, and thinking about what else needs to be added.
0.07 will include inlined primitives. This is to make #at: fast again,
specialised primitives have slowed it down a lot. But what else?

I currently think that getting full inlining in place as soon as
possible is sensible. This will make common sends free.  Also dynamic
inlining will have a big effect on how the compiler should be used so
adding it soon will make all decisions afterwards much easier.

But, what's slow and could be improved by compilation? I'd like a few
application benchmarks. Preferably benchmarks that take about a second
to run.

I'm not going to add support for floating point or blocks
next. Optimising floating point with primitive inlining would be
possible, without it is much harder because the interpreter favours
integer performance. Blocks require the same deep changes as inlining,
so are a good candidate just after full inlining. Full inlining with
blocks is very interesting because that would make do: and friends
free.

I'm also not interested in porting to other architectures or operating
systems. I'd rather make it really useful on one platform before
porting to others. However, I'd be very pleased to help others port if
they feel the itch.

So, could people please provide benchmarks of important code that's
slow and should be made faster with Exupery. I'd like to add them to
my benchmark suite which is used to tune Exupery.

Exupery should be able to optimise code that works mostly with
SmallIntegers, objects, and sends. Sends are now over twice as fast as
the interpreter. Code that spends most of it's time in primitives is
out, I could speed up primitive calls, but not their execution.

I'd really like benchmarks that are important. Think code that's
either slow and a pain now or where more speed would lead to the
Squeak community growing. Performance that increase Squeak's
commercial usefulness definitely are important.

Bryce



More information about the Squeak-dev mailing list