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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Saturday, October 07, 2006 1:26 AM To: The general-purpose Squeak developers list; [email protected] 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 [EMAIL PROTECTED] 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 [email protected] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery _______________________________________________ Exupery mailing list [email protected] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
