Exupery is now faster than VisualWorks for the bytecode benchmark

stéphane ducasse ducasse at iam.unibe.ch
Sun Apr 10 17:40:24 UTC 2005


Hi bryce

I'm not expert but I wanted to know how you plan to deal with mega 
morphic methods
such as printOn:.

After some benchmarks in visualWorks it seems that they have a cache 
with 8 entries.
At esug in southampton eliot gave a talk about the tragedy of PIC 
explaining that but there were no slides
and now I forgot :(.

Stef

On 10 avr. 05, at 17:30, Bryce Kampjes wrote:

> Exupery is finally faster than VisualWorks for the bytecode
> benchmark. There is still plenty of room to tune Exupery's bytecode
> performance. It's major advantage is it uses a colouring coalescing
> register allocator.
>
> For Exupery running in Squeak:
>  '694,237,288 bytecodes/sec; 14,295,065 sends/sec'
>
> For the Squeak interpreter:
>  '204146730 bytecodes/sec; 6390893 sends/sec'
>
> For VisualWorks:
>  '687,248,322 bytecodes/sec; 82,031,109 sends/sec'
>
> And my standard benchmarks comparing the interpreter to Exupery.
>  Benchmark		   Interpreter	 Exupery      Ratio
>  arithmaticLoopBenchmark   1595 compiled  132  ratio: 12.083
>  bytecodeBenchmark	   2459 compiled  715  ratio:  3.439
>  sendBenchmark		   1776 compiled  816  ratio:  2.176
>  gifConversion		   2042 compiled 1565  ratio:  1.305
>  Cumulative Time	   1942 compiled  589  ratio:  3.296
>
> It's still a lot slower than VisualWorks for sends but it it twice
> as fast as the interpreter.
>
> The plan is to rewrite the at: and at:put: implementation next. I'm
> going to use PICs to type check then compile a specialised version of
> at: for each receiver. This may make at: slower in the short term, I
> don't know. But it will mean that optimising at: will also optimise
> sends in general. And it will provide the machinery to optimise other
> critical primitives such as new:.
>
> After that I'm planning on improving Exupery's general reliability.
>
> The key question is what is the absolute minimum that needs to be done
> to make Exupery practically useful. There are plenty of largish
> projects that could make Exupery much faster, but being useful is
> important too.
>
> Bryce
>




More information about the Squeak-dev mailing list