Exupery

exupery@lists.squeakfoundation.org

107 discussions

Is it worth delaying the release?
by bryce＠kampjes.demon.co.uk 14 Nov '06

14 Nov '06

Is it worth delaying the release until after the 3.9 upgrade and the VMMaker upgrade? I've just started moving to a 3.9 image. There are 24 failing tests, most are because 3.9 produces different bytecodes than 3.8 for some things. This seems to be due to block processing but I haven't fully investigated. There are a few other failures including one due to a bug in 3.9. Is it more useful for me to release as is. A solid release on 3.8 before moving to 3.9 or to upgrade everything now. I'm going to upgrade next anyway. I'm not going to maintain different tests for both releases so once I fix them for 3.9 they will fail in 3.8. Bryce

4 13

Exupery 0.10 is nearly ready.
by bryce＠kampjes.demon.co.uk 12 Nov '06

12 Nov '06

It passes all it's tests and it also passes the stress test without any compiler errors. This is a first, until now the stress test only passed without crashing, a few methods failed to compile due to caught compiler bugs. Here's some performance figures: =============================== arithmaticLoopBenchmark 1401 compiled 92 ratio: 15.228 bytecodeBenchmark 2139 compiled 459 ratio: 4.660 sendBenchmark 1580 compiled 683 ratio: 2.313 doLoopsBenchmark 1093 compiled 843 ratio: 1.297 largeExplorers 344 compiled 373 ratio: 0.922 compilerBenchmark 739 compiled 691 ratio: 1.069 Cumulative Time 4205 compiled 1443 ratio 2.914 I'm now trying to build a 3.9 Exupery image on top of the squeak-dev images. If it works, I'll add it to the release. The release is on SqueakMap but not yet published. Bryce

1 0

question
by Chris Muller 25 Oct '06

25 Oct '06

Hi Bryce, great job on your perseverence, sounds like you're getting close! My interest is seething, as I'm sure many in our community, don't quit now, ok? :) I have been thinking in terms of Magma's materialization process, whether Exupery could deal with it. When an object graph is materialized from a ByteArray, the object structure is built in two steps. The first step establishes identity <-> oids by instantiating all of the objects with pointers to Integer oids, potentially Large or Small. For example, aPerson (110) name = 115 address = 130 aName (115) first = 116 last = 117 'Chris' (116) 'Muller' (117) anAddress (130) street = 141 '101 W. Meyer' (141) The second step then replaces those integers with the actual objects (or a proxy). aPerson name = aName address = anAddress anAddress street = '101 W. Meyer' If a particular variable can have an Integer, Proxy or the RealObject at various times, will that disrupt Exupery's ability to optimize the domain code, or am I confusing with Strongtalk?

2 1

Is it worth releasing now?
by bryce＠kampjes.demon.co.uk 24 Oct '06

24 Oct '06

Exupery now produces a noticeable speed improvement for the compiler benchmark. This is the bytecode compiler. I'm now going to work on reliability. It's probably more reliable now than the last release. arithmaticLoopBenchmark 1395 compiled 92 ratio: 15.163 bytecodeBenchmark 2131 compiled 457 ratio: 4.663 sendBenchmark 1588 compiled 697 ratio: 2.278 doLoopsBenchmark 1088 compiled 657 ratio: 1.656 largeExplorers 326 compiled 359 ratio: 0.908 compilerBenchmark 727 compiled 699 ratio: 1.040 ======================================================== Cumulative Time 4140 compiled 1370 ratio 3.022 The two most interesting benchmarks are largeExplorers and the compilerBenchmark. largeExplorers opens a large explorer window, it's an example of slow Morphic behavior. They are the two real world benchmarks, both purely use profiling to drive compilation, and both are real applications. The other benchmarks are micro benchmarks. The gains to compilerBenchmark are obtained by spending only 5% of the time in compiled code and it's support routines. The gains should be able to be improved by both better profiling and tuning. largeExplorers calls #@ frequently to construct points. This is a normal Slang primitive for native code but the interpreter inlines it into a special bytecode. Writing Exupery intermediate versions of #@ and #new would allow Exupery to generate optimal code for object creation that will be inlined by the primitive inlining system. The decision is whether to release as soon as all known testable quality problems are fixed or to implement #new and #@ before releasing. Releasing is quick on my side. The current development code includes Andy's changes to allow Exupery VMs to be built on Windows. Bryce P.S. Tony, the bug we were looking at on Saturday is now fixed. It was caused by an accidental indirect recursion consuming all the C stack. The change to newNativeMethod stopped exuperyBlock:Value: from realizing that it was called from compiled code so it called compiled code directly instead of setting newNativeMethod and returning.

2 2

RE: Porting
by bryce＠kampjes.demon.co.uk 15 Oct '06

15 Oct '06

Hi David, David Griswold writes: > If all that happens is that whenever a typecheck fails you jump > to a single alternate flow of control that does only sends and avoids > all inlining, then that sounds like the equivalent of an uncommon trap, > except that you lose the biggest advantage of deoptimization, which is > that compilation and inlining are completely transparent to the debugger > and all other kinds of context reflection. > > How does Exupery compiled code work with the debugger (especially when you > start doing inlining)? How would the reflection that for example Seaside > does, work with > compiled contexts? Exupery can decompile a context at any time, it's just done in the image by using reflection. Contexts are just normal objects in Squeak and Exupery adds it's own context classes. Exupery's contexts are responsible for converting themselves into interpreted contexts when necessary. (1) If anything is done to an Exupery context that could invalidate the assumptions of compiled code then the context should convert itself to an interpreted context. So if the debugger trys to change a context it should convert itself back to an interpreted context. The profiler however should not cause contexts to convert themselves to interpreted contexts. It's the ExuperyContext's responsibility to convert itself into an interpreted context when Seaside serializes it. Seaside could serializes an ExuperyContext but that could cause a crash if the ExuperyContext converted itself into an interpreted context then Seaside recreated the stack with it in. ExuperyContexts have different instance variables to interpreted contexts so filling an interpreted contexts variables using instVarAt:put: after taking them from an Exupery context with instVarAt: is dangerous. If Seaside calls a context to save itself rather than using instVarAt: to get the state out then making it work with Exupery is easy. An Exupery context could also convert itself if instVarAt: is called on it. ExuperyBlockContext>>convertToInterpretedContext will convert an Exupery block into an interpreted block. It re-arranges the instance variables then calls primitiveChangeClassTo: to change the class. Exupery manages it's code cache purely in the image. It needs to convert all Exupery contexts back to interpreted contexts before flushing the code cache or saving the image. Otherwise it may try to execute compiled code that's not there. Uncommon traps are definitely a very nice optimization for a fast compiling compiler. By removing the need to produce the code they speed up compilation. However uncommon traps do make it harder for a slow compiler that trys to produce very fast code. > Strongtalk doesn't do any of that right now. The normal uncommon trap > mechanism, combined with our use of 0 tags for SmallIntegers, means that > SmallInteger arithmetic is very fast already, since addition for example > doesn't require any tag manipulation at all, so we don't really have to > worry about conversion/deconversion issues. I was thinking about true 32 bit integers not SmallIntegers. True 32 bit integers are needed for a few applications such as cryptology. The Squeak cryptography guys are currently writing a few primitives to speed up their inner loops. > As for double precision floats, they could be done the way you are > suggesting, which would be nice, but right now they are not done that way. > Right now our "fast float" experiment uses special bytecodes that treat them > as a non-OO basic type (with explicit conversion to and from objects). But > that was just a quick experiment that Robert Griesemer did, and it is not > really part of the "language", although they work and are very fast. Sounds interesting, I'd like to talk more about it when I'm ready to start work on floating point. Bryce (1) The description is true for block contexts but not method contexts. Exupery method contexts currently share the same class as interpreted method contexts. I'll create their own class before 1.0. Before blocks the old style Exupery method contexts were executable by a normal VM which was very nice for early bootstrapping. This also meant that the debugger would work for them unless it was single stepped. The decompilation code is present and well tested. What's missing is the hooks to trigger decompilation when a context is manipulated via reflection.

1 0

Re: Cryptographic Primitives
by bryce＠kampjes.demon.co.uk 08 Oct '06

08 Oct '06

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

2 3

Exupery is not JIT (was Re: Cryptographic Primitives)
by bryce＠kampjes.demon.co.uk 07 Oct '06

07 Oct '06

tim Rowledge writes: > Actually I don't think JIT is a sensible description at all; it isn't > accurate and it doesn't really indicate the advantages that Exupery > could have. For example, no extra startup costs, easier extension/ > maintenance/optimising because it is written in a sensible language, > access to all of the reflexive capabilities of the system, trivial > fallback if the system is run on an unsupported platform (it just > doesn't do the compiles and leaves everything to the interpreter), > potential for using a spoon-like inter-image communication system to > allow the compiles to run in a different image/machine, and... well I > could probably go on. Well, most people only really understand the static compilation model of C/C++, and the dynamic compilation model of VisualWorks and Java. They call any form of dynamic compilation a JIT. Many so called JITs compile in the background. I think IBM's Jalapino does background thread compilation. Exupery is in some ways closer to a Lisp compiler written in Lisp than a Deutsch-Schiffman influenced JIT. So, you could say it's drawing on a tradition that goes back to at least the '70s. Help is always appreciated. Exupery is a test heavy project, this should help people get up to speed. Tests are required for everything. If anyone would like to help please join the Exupery mailing list and ask. http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery There's a list of things to do before 1.0 here: http://minnow.cc.gatech.edu/squeak/5793 If you're thinking of writing hundreds of primitives for speed then helping out with Exupery is probably the best use of your time. If you're thinking about writing tens of primitives then it's debatable. If you're only thinking of writing a handful of primitives the just write the primitive unless working on a compiler is it's own reward. Going back to crypto. From what I understand about SSL writing the streaming cyphers as primitives should make sense for the next few years. Writing public key primitives would require some serious profiling first as they're only used once per session. But we all vote with our time. Just don't get upset if in 5 years time you're rewriting cyphers into Smalltalk from primitives for speed. Bryce

1 0

trying to see Exupery in action
by Chris Muller 06 Oct '06

06 Oct '06

Hi, I would like to see some indication of Squeak going faster with Exupery under Windows. I folllowed the instructions at http://minnow.cc.gatech.edu/squeak/3945. - downloaded the Windows VM and replaced my squeak.exe. F2 | Version Information reports "Squeak 3.7.1 (release) from Sep 18 2006". Is this right? - I then installed Exupery-wbk.206 from SqueakMap. Then ran the ExuperyStoryTests. All but two passed. - Still, I was eager so I did "0 tinyBenchmarks". Unfortunately I got the same #'s I got with another image without Exupery. I tried it a couple of times. - I then loaded the Exupery from SqueakMap and reran the tests. Same two failed. Ah, I need CommandShell and GraphViz loaded! - So I loaded CommandShell to try making those other tests pass. (When it reached that test it gave a bunch of errors saying it was going to stdout (looked like a mixed Unix/Windows filename), oh well). I didn't install GraphViz, I just don't think this is the problem; I am sure I am doing something else wrong. Any suggestions are appreciated.. - Chris

3 2

Strongtalk and Exupery
by Bryce Kampjes 24 Sep '06

24 Sep '06

Hi David, It's great to see that the Strongtalk VM has been open sourced. Hopefully, it will be an asset to the community. Does the Strongtalk mailing list have a publicly available archive? One that doesn't require a yahoo sign-on? It would make it much easier for interested outsiders to follow what's going on. How does Strongtalk compare with current Java Hotspot VMs? They are also available with source for study (though not open sourced). I'm the primary author of Exupery, another attempt at fast execution technology for Smalltalk. Exupery is written in Smalltalk. The original design was to combine Self's dynamic inlining with a strong optimising compiler. For that the goal, I don't think we can afford to write in anything less productive than Smalltalk. That is still the goal but it's a long way off, Exupery is currently moving towards a 1.0 without full method inlining and without a strong optimiser. All the needed high risk features are there. Compile time is not the key issue for a dynamic compiler, pauses are. Compile time only becomes critical if you are stopping execution to compile. Exupery doesn't. Being normal Smalltalk like everything else pausing execution to compile is tricky. The trade offs to allow Exupery to be easily written in Smalltalk are the same as those required to allow long compile times for high grade optimisations. If you, or other Strongtalkers are interested in talking about compiler design please feel free to join Exupery's mailing list. Don't worry if you don't have time to study the source or play with it. Sharing experience would be valuable. Exupery is now about 4 years old, revisiting the design decisions with knowledgeable people would be useful, especially in an archived list. Exupery is another chance to keep the ideas and vision alive, if not the C++. The Exupery mailing list is here: http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery Exupery's tiny benchmarks are: 1,176,335,439 bytecodes/sec; 16,838,438 sends/sec and with the interpreter: 228,367,528 bytecodes/sec; 7,241,760 sends/sec Which makes it currently much slower than Strongtalk for sends but the same speed for bytecodes. That's comparing against the numbers provided by Gilad via Dan's post to squeak-dev. Such a comparison is not fair as relative performance does vary greatly with architecture. Exupery is best on P4's, ok on Athlons, and least impressive on Pentium-Ms. The bytecode performance is the most interesting to me. Exupery does not yet do dynamic method inlining which explains Strongtalks strong send performance. Message inlining is not necessary for a 1.0. That the bytecode numbers are so close, and I know Exupery's weaknesses, is interesting. Exupery uses a colouring coalescing register allocator but also lives with Squeak's object memory and could do with a bit more tuning. I'm guessing Strongtalk's object memory is much cleaner and better designed for speed based on reading the Self papers. Did the Strongtalk team stop tuning for bytecode performance after they passed VisualWorks? Exupery has also recently been ported to Win 32 and Solaris 10 x86. Both ports were done by other people. Pre-built VMs will be available for both platforms in a few days. Bryce

2 4

[ANN] Squeak VM for Windows.
by Bryce Kampjes 23 Sep '06

23 Sep '06

Many thanks to Andrew Tween for porting Exupery to Windows. The VM is here: http://ftp.squeak.org/Exupery/vms/exupery-vm-0.09-win32.zip The installation instructions here: http://minnow.cc.gatech.edu/squeak/3945 Now include both Windows and Solaris. Does anyone feel like trying to compile it on the x86 Mac? The Mac should be easier than Windows unless Apple redefined the C calling conventions which I doubt. Bryce

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Exupery