Looks like Exupery is in the spotlight in these days! Many messages ha appeared on the Squeak-dev mailing list asking questions and details about this project. Bryce Kampjes and others provided answers to these questions here, here, and here.
Also, don’t forget to read to our little Exupery FAQ!
In replying to a question on the Beginners mailing list, Yoshiki Ohshima explained the startup process of a Squeak image, from the moment the VM is invoked by the operating system, to the moment the user can start interacting with the Squeak system.
Giovanni Giorgi has tried Exupery, the Squeak byte compiler written by Bryce Kampjes. Exupery is still in beta but is usable for experimenting.
The Weekly Squeak is happy to publish a prime-time FAQ on it.
Introduction
First of all, the master reference for exupery is the omnipresent wiki.
I have done a small interview to Bryce Kampjes, and we ended up building an interesting FAQ for Exupery.
Q: What is Exupery?
A: Exupery is a native code compiler for Squeak. It translates byte-code into machine code. It can compile most methods which don’t include primitives and a handful of primitives. It is becoming something like a JIT but with the compiler written in Smalltalk. At the moment, it can dynamically inline a handful of primtives but not full methods.
Q: Exupery is not only a “Just in time compiler” (JIT) as we will see in the next few answers. What does “Exupery” means?
A: It’s named after a French author and early aviator.
Q: I have installed if from SqueakMap. How can I use it?
A: Instructions in the wiki pages above. But you’ll need a custom VM. I’ve had to modify the VM so it’ll jump into the native code from interpreted code. For now you need to manually compile methods.
In the latest development builds the following is good:
ExuperyProfiler optimise: [ExuperyBenchmarks new compilerBenchmark].
Exupery dynamicallyInline.
The first line profiles the expression in the block then tries to compile the hot spots. The second line inlines any primitives called by compiled code.
[See this link for the VM]
Q: Can I compile my class and try it at my own risk?
Sure.
Q: Can I compile only some classes?
Exupery will only ever compile some methods. It’s goal is to compile frequently called methods well producing good code, rather than all methods quickly. You tell it to compile methods rather than classes.
Q: How much stable is Exupery? Can I use it for my important Flower Collection Blog? (Ok I was just kidding, I haven’t a Flower blog… 😉
Yes, but it’s still an alpha compiler. Expect bugs and crashes. If you really need to speed up your blog, then compile the critical methods and script compilation. Don’t let Exupery use it’s profiler or any dynamic compiler in production. That should allow you to test it better.For now, if you really want to use it in production explicitly compile the methods that you think will lead to a speed gain then test it. This should reduce the risk of crashes.
Q: Can I use MessageTally to profile Exupery and compare against interpreted code?
Not at the moment. The problem is compiled code does not check for interrupts so MessageTally will never see it.To compare use
Time millisecondsToRun: [...].
Q: I want to come back! Is it easy?
You can always stop using Exupery. At any point you can tell it to remove all compiled code from the system. There are VM hooks, but it removes all compiled contexts before saving so it’s always possible to go back to a vanilla VM. If you go back to a vanilla VM you are in exactly the same place you were before you started experimenting with Exupery (besides having a few extra classes in the image).
Q: I’d like to work on Exupery. Where should I start?
Q: Join the exupery mailing list and ask for things to work on. Say what you’re interested in doing. If you email me, I’ll reply.
There’s a decent amount of stuff to do. The first thing is probably building an Exupery VM. For most things it helps to have a local build environment both for staying current and for debugging. If you’re just working on in-image stuff, say the profiler or testing then you could live with pre-compiled VMs. But if you want to work on new primitives or features then you’ll need to be able to debug. At a minimum that involves recompiling VMs to add logging.
I can only supply Linux VM’s. If you’re running another OS, then you’ll need to build your own or get one from someone else.
Final words
We thank a lot Bryce Kampjes for the rapid reply. We hope this FAQ will help Squeak fan to try Exupery. That said, your comments are welcome: please ask more question so that we can enhance this document.
We feel that Exupery is a very interesting project, and can attract many developers because of the performance gain.
Craig Latta has setup a page on Squeak People in order to gather agenda items for the biweekly IM meetings of the Squeak Foundation board. Anyone interested in suggesting an item may do so by leaving a comment to Craig’s article.
Craig Latta posted a new progress report on his Spoon project, which aims to create a minimal live system based on Squeak.
Craig announces that in his quest for getting a really minimal system, he managed to remove the SystemDictionary class, a class that plays a fundamental role in a standard Squeak (and Smalltalk system).
The current implementation of CompiledMethods objects is quite complicated. This is due to the fact that this class is one of the most important for the Squeak VM: it holds the information the VM needs to execute a method. This meant that many of the changes that have occured on this class focused on backwards compatibility instead of design simplicity.
Tim Rowledge has recently proposed a new format for CompiledMethods objects which would semplify not only the internals of CompiledMethods, but some other parts of the system too. This modification is based on an older proposal of Tim dating to 1998.
Tim proposal sparked a discussion on Squeak-dev that, albeit a little difficult, is very interesting to read.
Pavel Krivanek posted to the Squeak-dev mailing list the code for a simple test server implementation, to automate running of the Squeak SUnit tests.
The Cryptography Team released the first version of Squeak SSL! http://lists.squeakfoundation.org/pipermail/announcements/2006-October/000050.html . There is still much to be done, but it’s nice to see the team on the move. Come join the team http://lists.squeakfoundation.org/mailman/listinfo/cryptography .
The code can be found at www.squeaksource.com/Cryptography . Special thanks to everyone that helped make this possible and espically Rob Withers for pulling it all together. Rob’s code is really beautiful.
There is still plenty of work to be done so please stop by and volenteer to help!
Ron Teitelbaum * Cryptography Team Leader
Matthew Fulmer has announced the creation of a Documentation Team. The purpose of this new team will be the production and mantainance of Squeak releated documentation: tutorials, references and the like.
The team will start by compiling an index of the existing documentation, and by starting a Squeak developer tutorial.
We’d like to wish Matthew and the other team members a good work!
Dan Ingalls pointed out that Strongtalk is now open source. The community now has an important opportunity and decision to make. Should we work with Strongtalk to build a Strongtalk VM for Squeak. There are a number of potential advantages to this path (see www.strongtalk.org) . There could also be risks. As our community changes it is important that issues like these be addressed publically, so that a broader range of the community can participate. Please join the discussion and move this issue forward while the opportunity still exists.
Dan followed up on his original post with a Community Challenge:
Tell ya what…
Here’s $5000 that says “some smart guy” will do it before the end of 2006.
<lays money on table with a bottle of champagne on top>
😉
UPDate: David Griswold and Dan Ingalls call for VM Summit on: http://groups.google.com/group/strongtalk-general
see: http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-October/109526.html for details
The Weekly Squeak 