Cryptographic Primitives
barger
barger at barnet.sk
Sat Oct 7 12:56:40 UTC 2006
Hi,
Excuse my inconvenience Bryce, but will be Exupery somedays able to compile
whole VM ?
I see that this is not the main direction of it now, but in near future it
can be huge help at least for SQUEAK NOS and also for Squeak 64 bit VM.
Maybe can be your work reused someway for slang ST to direct machine code
compilation...
What do you think about this idea ?
Thanks
Jan Barger
www.barnet.sk
-----Original Message-----
From: exupery-bounces at lists.squeakfoundation.org
[mailto:exupery-bounces at lists.squeakfoundation.org] On Behalf Of
bryce at kampjes.demon.co.uk
Sent: Saturday, October 07, 2006 1:26 AM
To: The general-purpose Squeak developers list;
exupery at lists.squeakfoundation.org
Subject: Re: Cryptographic Primitives
Andreas Raab writes:
> J J wrote:
> >> No. First, Exupery is not a JIT.
> >
> > I had been told it was. In this list actually.
>
> Yeah, it's quite confusing actually. I found the statement that
> "[Exupery is] a "JIT" for Squeak that doesn't compile just in time"
> which (to me) makes no sense as "JIT" stands for "just in time" so how
> could a JIT not compile just in time? ;-)
When Exupery is running in a background thread a user shouldn't
notice that it's not a "real" JIT. So calling it a JIT is fair.
It does not stop execution to compile like the VisualWorks VM does.
This means it must fall back to the interpreter if compiled code
doesn't exist. It can't compile "just" in time. It can compile just
afterwards though.
I'll write an up to date overview of what Exupery is, what it plans to
be, and what it does now soon. Either before or just after the next
release.
All that's left to do before releasing is implement the two primitives
#new and #@ then fix some bugs. The two primitives are required for
the largeExplorers benchmark.
Here's the current benchmarks.
arithmaticLoopBenchmark 1395 compiled 91 ratio: 15.330
bytecodeBenchmark 2132 compiled 456 ratio: 4.675
sendBenchmark 1588 compiled 684 ratio: 2.322
doLoopsBenchmark 1086 compiled 649 ratio: 1.673
largeExplorers 337 compiled 366 ratio: 0.921
compilerBenchmark 794 compiled 767 ratio: 1.035
Cumulative Time 4241 compiled 1389 ratio 3.053
The most interesting benchmarks now are largeExplores (opening a very
large explorer) and compilerBenchmark (compiling a large method into
bytecodes). Both are real uses. Both use a profiler to choose methods
to compile then PIC based type feedback to inline primitives.
largeExplorers needs a faster #@. The interpreter inlines this into a
bytecode while Exupery is currently doing a full message send. Once
it's implemented as a compiled primitive it will then get inlined
automatically.
compilerBenchmark is spending 5% of it's time in compiled code and
support routines. That provides a 3.5% gain. Better profiling may help
by compiling more methods. I haven't looked at the profiler since the
last optimisation. So would a little tuning, 1% of the time (out of
5% in compiled code) is spent building the new context during a
message send, most of that time could be saved. It is however
producing a performance gain. Which is enough to make bug fixing the
priority again.
The list of things to do before a 1.0 is here:
http://minnow.cc.gatech.edu/squeak/5793
Nothing on it is hard or risks destabilising things.
Bryce
_______________________________________________
Exupery mailing list
Exupery at lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
More information about the Exupery
mailing list