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
|