Exupery

exupery@lists.squeakfoundation.org

107 discussions

Exupery VM build troubles
by barger 21 Dec '05

21 Dec '05

I have troubles with recompilation of current Exupery VM. It seems that compilation need a C support files, but http://squeak.hpl.hp.com/svn/squeak/tags/unix-3.7-7 is not usable anymore. Can anybody give me direction how to download these files ? Thanks. Jan Barger www.barnet.sk P.S. This hp.com server was a bad choice ( also for 64bit squeak repository ). If anybody will need stable ftp or http server for lon time period i can offer some space and 10Mbit bandwidth for free ( we are Internet Service Provider here in Slovak republic, Europe ).

3 2

Creating new context classes for Exupery
by Bryce Kampjes 13 Nov '05

13 Nov '05

I've just started work on compiling blocks but unfortunately there isn't a spare slot in BlockContexts to hold a pointer to the natively compiled code so I'm thinking about creating context classes for Exupery. The new contexts will be removed when Exupery is shutdown or Exupery's code cache is initialised because they will hold pointers to compiled code which isn't saved with the image. However they will need a compact class number so they can be checked for. This is important because the GC needs to check if an object is a context so it can deal with the stack. If I use a compact class then the extra check will just be an extra integer comparison. I'll probably swap the position of the caller and the instruction pointer for Exupery's contexts. This way an integer check of either position will indicate if it's an Exupery compiled context or an interpreted context. Exupery's instruction pointers are pointers to compiled code tagged as integers. The caller or sender slot should always be a pointer object not a SmallInteger while both Exupery instruction pointers and interpreted instruction pointers are always SmallIntegers. Would checking the instruction pointers size be more sensible? In practise it would be safe but there's a risk that the code cache might be allocated at memory location 0 on some platforms. I'll need to use my own contexts for natively compiled methods as well once Exupery starts inlining methods. This is so that image level code will be able to hide the inlining or de-inline if necessary (say when single stepping in the debugger). Any objections? Bryce

1 0

What should be in the next release.
by Bryce Kampjes 09 Nov '05

09 Nov '05

The big question is whether to work on blocks next. Out of the the four key missing features blocks are the most disruptive. I'll have to create my own context objects which is a major but small change to the interpreter. It will also make the Exupery shutdown code more important because an unmodified VM will not understand these new context objects and require image support code to deal with compiled contexts (say for debugging). The top four items are: * blocks * super sends * new * integration (making primitive inlining usable and the the profiling compiler effective) They have been chosen based on profiling slow operations including the Magma LargeInteger benchmark, the bytecode compiler, and opening explorers on large Arrays. I suspect that with all of the above done Exupery will have a minimally useful core. It would still need a few more critical primitives but which ones will then depend on what you want to speed up. At the moment, everything needs at least three of the four features above. At the moment, I'm leaning towards blocks next. Any thought? Bryce

3 5

The next release.
by Bryce Kampjes 08 Nov '05

08 Nov '05

I'm just preparing the next release of Exupery. This release is just bug fixes. It's now reliable enough to play with. Installation instructions are here: http://minnow.cc.gatech.edu/squeak/3945 There's a compiled VM for Linux there. Get the Squeak code from SqueakSource for now, I'll place it on SqueakMap soon. Some feedback on the documentation here would be great: http://minnow.cc.gatech.edu/squeak/Exupery Bryce

1 0

I'm new to the list
by Klaus D. Witzel 06 Nov '05

06 Nov '05

Hi list, I just read (in the #squeak IRC log) that this list is now served by news.gmane.org, so it's time for me to subscribe :) I have two interests here: tracking of news for The Weekly Squeak ( http://minnow.cc.gatech.edu/squeak/5740 ) and learning new ways (& tipps & tricks :) on how performance constraints can and will influence development of outstanding software (emphasis on but not limited to Squeak). I have just finished tweaking Squeaks's VM for allowing me to define sort of "basic" ClassBox for which the VM can report: - memory allocation and reclamation - message sends entering the box - message sends within the box - message sends leaving the box When the box (which can be redefined in Squeak without compiling the VM) is empty, the above changes have less than 1% performance penalty on bytecode execution and less than 10% performance penalty on message sends (relative to '0 tinyBenchmarks'), so are almost acceptable even for HTTP servers and multimedia applications. My next steps are to brain storm and populate example boxes as representable sets which exhibit interesting characteristics. For example, "what Number methods are involved in Collection operations", "what Magnitude methods are involved in BitBlt operations", just to give an idea. The boxes I define have two configurable components: the out-of-box behaviors and the in-the-box behaviors, that's what makes them flexible. I'd be happy to receiving *any suggestions* for example boxes from members of the list, for example what is currently defined for benchmarking Exupery. /Klaus

1 0

Welcome and where we're at
by Bryce Kampjes 06 Nov '05

06 Nov '05

Exupery is an attempt to make Smalltalk fast, as fast as C in many cases. We're nowhere near that at the moment. The short term goal to make the current system practical is much more important now. The current release is slowly getting ready, I've got two bugs to fix. This release has been mostly debugging. It's much better. The stress test runs to completion. The stress test runs all the test classes in the system then compiles the top ten methods from each class then reruns it. That should be a reasonable test to show that Exupery is reliable enough to play with. This is the SqueakSource version not the released SqueakMap version which is buggy. Currently, I think the next release should have block support and super sends. That will mean that Exupery will compile most methods. There's a long list of things that could be done now, however the trick is figuring out what's needed to make Exupery useful. The list I can think of is: * Block support * Super sends * Specialised inlined #new. * Full method inlining * A 64 bit port * Floating point support (faster, not fast) * 32 bit integer support (like the floating point support) * Instruction Scheduling (for P3s including Pentium Ms). * Ports (that's up to you) Block creation is not currently compiled. This means that any method that creates a real block isn't compiled which is a surprisingly large number of loop methods. Exupery only speeds up calls from compiled code to compiled code so compiling a full loop is important. Super sends also are fairly common. Compiling both blocks and super sends should mean that Exupery can compile everything required by the compiler excluding primitives. Profiling opening explorers on large lists (suggested by Eddie) showed that a lot of time was being spend in either methods with blocks or #new. The #news were often indirect, say hidden in a @ method. About 40-50% of the time was in #news as far as I could see. Better analysis would help including some C/oprofile based profiling. Squeak's #new is very slow, it spends a lot of time figuring out what the object's shape is while creating a new object. By compiling a specialised version of #new for each object this can be heavily optimised. The above three should provide most of the "easy" gains for normal Smalltalk code. The rest of the "easy" gains will be compiling primitives directly to customised machine code. That's best driven by profiling. There are a lot of primitives and only a few will matter for each hotspot. The next big architectural addition is likely to be full method inlining. This provides a few benefits. First it'll make common message sends very quick. Second adding it will change the cost/benefits of other optimisations. If enough sends are inlined then optimising the less common cases becomes less important and inlining creates large methods with more opportunities for other optimisations. The main reason to consider a x86 64 bit port is to make Exupery more portable. So far I've been focussing on making it useful on one platform and a few portability details have been ignored. An x86 port would be a nice small port but still require cleaning up the portability issues. Exupery almost has a decent architecture to optimise floating point expressions. What's missing is combining primitive inlining with type feedback. Exupery currently does both, I just haven't glued them together. The key to fast floating point without a full SSA optimiser is removing boxing and deboxing floats inside an expression and speeding up object creation (the same as #new above). 32 bit integers have exactly the same optimisation problems as floats. This is assuming that the 32 bit integers are stored in their own objects with primitive that do 32 bit math rather than using two SmallIntegers. Exupery performs badly on P3 cores, it's still faster than the interpreter. This is because they have an asymmetric instruction decoder. The chip decodes up to three instructions at once but only the first one can be a complex instruction. Exupery will often generate several complex instructions then a sequence of simple instructions. Instruction selection could both reduce register pressure by moving instructions closer to those that create the values they use and deal with the P3's problems. Then there's ports. Rick has started a PPC port. OK, so that's the things that might be worthwhile starting soon. The strongest arguments are either significant benchmarks or code. Benchmarks should be things that I can add to ExuperyBenchmark, so no licencing issues and preferably that only use code in the base image or standard (whatever that means) packages. Bryce P.S. The outline above is too brief but hopefully it'll give you a flavor of where Exupery is currently and where it could go in the near future.

2 1

how can I try?
by Chris Muller 06 Nov '05

06 Nov '05

> The stress test runs all the test classes in the system then compiles > the top ten methods from each class then reruns it. That should be a > reasonable test to show that Exupery is reliable enough to play with. > This is the SqueakSource version not the released SqueakMap version > which is buggy. Congratulations Bryce on this great work (in progress), and thanks too. The idea of a significant speed increase "for free" is very exciting to me. After reading the pages at http://www.kampjes.demon.co.uk/ it's evident the complexity involved to achieve this is staggering. I would like to get a whiff of it; I have some indexing stuff that spends most of its time doing Integer (including LargePositiveInteger) arithmetic, encapsulated into four or five methods. I am very curious to run my test case in an Exupery-loaded image. Does it work in Windoze at the moment? Sorry, I did not find install / operational details on the site. I did load the SqueakSource version 113 but did not see any improvement in 0 tinyBenchmarks so I didn't bother with my indexing test.. - Chris

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Exupery