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
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@lists.squeakfoundation.org [mailto:exupery-bounces@lists.squeakfoundation.org] On Behalf Of bryce@kampjes.demon.co.uk Sent: Saturday, October 07, 2006 1:26 AM To: The general-purpose Squeak developers list; exupery@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@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
barger writes:
Excuse my inconvenience Bryce, but will be Exupery somedays able to compile whole VM ?
It would be possible. But then you'd end up with a system like CMU Common Lisp. I'm not sure that would be more portable than our current system with Slang compiling to C.
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...
I think we've got a 64 bit VM now thank's to Ian and Dan's work. I haven't yet tried compiling it myself but mean to in the next few weeks.
What do you think about this idea ?
It's interesting, it really depends on your goals. There's nothing that would stop you doing it.
I'd probably try to write the interpreter in Smalltalk then statically compile it using Exupery into assembly then run the assembler through gas. The only reason to use gas is to avoid dealing with linker formats. For SqueakNOS compiling to machine code should be possible. But you'd have to rewrite all the C in the interpreter you need into Slang or preferably Smalltalk.
So, you'd end up with the object memory written in Slang then as much of the interpreter as possible running as regularly compiled Smalltalk. There is a bit to think about to lift the interpreter up to "statically" compiled Smalltalk. But once it's done you should be able to recompile bits of it live to evolve it without needing to restart the image.
I'd suggest waiting a bit more before starting to use Exupery for such a project. If enough people are interested in doing it it could be done.
Bryce
Thanks for the answer, I will wait if Squeak NOS guys will move this or other way, and i will try to study any Exupery approaches in future.
Jan
exupery@lists.squeakfoundation.org
-
barger -
bryce＠kampjes.demon.co.uk