Exupery March 2009

exupery@lists.squeakfoundation.org

4 participants
7 discussions

[ANN] Exupery 0.15 released
by bryce＠kampjes.demon.co.uk 12 Mar '09

12 Mar '09

Exupery 0.15 is released and available via pre-built images, SqueakMap, and package universes. This release includes some significant bug fixes and a few performance enhancements. Instructions are here: http://wiki.squeak.org/squeak/Exupery The biggest practical benefit is a major bug has been fixed which makes running with Exupery much more reliable. Crashes are no longer expected after about an hour or so. The two major optimisations were adding more addressing modes and also compiling calls to the interpreters primitives. This means that code with many calls to primitives can benefit from Exupery's PICs. Compiling primitives is responsible for the doLoopsBenchmark showing a benefit again, Exupery used to perform identically to the interpreter on a Core 2. While Exupery can improve the macro benchmarks sometimes it will slow code down a little as well so practical performance gains with unrestricted compilation are still a release or two away. Here's the current benchmarks: arithmaticLoopBenchmark 390 compiled 80 ratio: 4.875 bytecodeBenchmark 724 compiled 250 ratio: 2.895 sendBenchmark 663 compiled 385 ratio: 1.722 doLoopsBenchmark 381 compiled 235 ratio: 1.621 pointCreation 394 compiled 389 ratio: 1.013 largeExplorers 269 compiled 210 ratio: 1.280 compilerBenchmark 273 compiled 250 ratio: 1.092 Cumulative Time 413.408 compiled 232.706 ratio 1.777 ExuperyBenchmarks>>arithmeticLoop 103ms SmallInteger>>benchmark 341ms InstructionStream>>interpretExtension:in:for: 6069ms Average 597.360 Next up dynamic inlining of entire methods. Exupery already dynamically inlines a few primitive calls. Discussion about Exupery is here: http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery Bryce

1 0

A design for full method inlining
by bryce＠kampjes.demon.co.uk 08 Mar '09

08 Mar '09

Inlining contexts requires care to ensure that it's possible to de-optimise them safely and that the semantics are never changed even when code is changed or when reflection is used. Things to consider: * De-optimisation * Blocks returning from the method and accessing state. * Changing code * debuggers and profilers (stack walking) * become: and changeClassTo: and #primitiveChangeClassTo: * other reflection including #instVarAt:put: * Seaside At the moment it's possible to de-optimise any context individually which is very convenient but means that the VM must not need to be aware of whether a context is native or interpreted except when it's executing it. The VM will refer to the home context of a block, so everything it accesses must be in the same locations whether interpreted or compiled. Being able to de-optimise a context without needing to worry if there are block contexts is a great simplification when ensuring Exupery doesn't cause crashes on de-optimisation. De-optimisation can be triggered by various things like saving the image, modifying a context, saving it in Seaside. Native contexts can not be in the image when it's saved as the machine code they depend on will not be there, and even if it is it's unlikely to be at the same location. Seaside, and the profiler have opposite problems for de-optimisation with Seaside we want to de-optimise the context to make it safe to persist while with the profiler we want to leave the context optimised so profiling doesn't change the performance characteristics. Currently de-optimisation only converts a context from native to interpreted, it uses the same object to represent both. With inlining de-optimisation will need to create contexts. Because we don't know what the contexts are for we should preserve identity including during de-optimisation. Any context that creates a block is referred to from the block so it'll need to be created. Only changing code will require removing inlining. Because of reflection we can not guarantee that data will stay the same from when we leave a method until when we return. But the method is decided at send time, so the type check that replaces the send is good enough to deal with this case. Inlined code will need to sanity check it's state on re-entry if it's relying on knowing the class of any variable, this can not be avoided because the class could have changed via primitiveChangeClassTo: or become:. The Design: =========== Simple methods that don't create contexts will be fully inlined into the calling context. A slot will be kept to hold a pointer to a "proxy" context if it is ever accessed via reflection, this lets the proxy context be reused if it's ever accessed again. The proxy context will access state in the parent context. If a method creates a block a real object will be created. It's variables and stack will be used, and so will it's PC. This is so that the block can return out of it via a ^ return into the surrounding part of the inlined context. While a context object will be created, the code dealing with it will be inlined, so the inlined method will manage multiple contexts depending on where it is. Always creating the context that creates a block ensures that it and the block can be de-optimised as de-optimisation will not change the location of the context's variables. If it was inlined into another context object then it's variables and stack would be located at a different location. Also the return code would need to do something special to return into it. If a block is inlined for it's entire lifetime then it can be removed fully. This is the the optimisation's goal because it's probably inlined an entire loop and if not sends will be converted to simple jumps inside the inlined method. If code is changed then initially all effected contexts will be de-optimised. This involves a full memory scan via allInstances to find the Exupery contexts. This could be optimised by either de-activating the inlining by modifying the code or using a context stack to minimise the amount of memory to scan. Modifying code to de-activate the inlining is the simpler optimisation, it just involves writing an unconditional jump over the type test to jump directly to the unexpected case thus avoiding the inlined code. ContextPart>>sender will need to be modified so the sender can answer it's newest inlined context rather than itself if it's an inlined context. De-optimisation will be done in the image without requiring any VM extensions. It may be worthwhile introducing a "uncommon" trap that lets compiled code bail out and de-optimise if the assumptions it's built for become invalid. At the moment native code can deal with both the expected and unexpected cases. Removing the need to deal with the unexpected cases should reduce the size of native code needed. Bryce

2 1

0.16 possible tasks.
by bryce＠kampjes.demon.co.uk 08 Mar '09

08 Mar '09

Here's a list if things that could be considered for 0.16 in rough priority order: 1) Full method inlining 2) Support for proper closures 3) Tuning to make the current compiler more useful 4) Saving the image without removing all native code 5) Saving native code with the image I've fairly much settled on 1) as the main part of the next release. It'll change the overall behaviour of Exupery so it's worth doing before focusing on tuning the profiler to pick the correct hot-spots. It's also hard to judge the value of other send optimisations until I can see how well dynamic inlining works. 2) would be nice and isn't that large. It'll involve freeing up the "unused" slot in MethodContext, Exupery uses it as a flag to indicate what methods are compiled and what methods are interpreted. That's a legacy from back when it was the native PC. After freeing up the "unused" slot closure support is just implementing a few more bytecodes. 3) was the original plan. As reliability has jumped up enough to tackle full method inlining and relative send performance is so much worse on Core 2 than it was on Athlon 1) looks more appealing. 4) and 5) will both make testing a little easier. Given Exupery is a slow compiler it shouldn't really throw native code away as readily as it does now. Being able to use native code for longer will add significantly to the practicality of Exupery but the driver at this stage is making long tests easier to perform. At this stage, I'd guess 0.16 will have 1) and possibly 2). Full method inlining is a fairly big task made up of various stages. Inlining methods that don't create blocks is much simpler than inlining methods that do refer to blocks. Bryce

1 0

PIC details
by bryce＠kampjes.demon.co.uk 06 Mar '09

06 Mar '09

Jecel Assumpcao Jr writes: > I am interested in the various efforts to add Polymorphic Inline Caches > to Squeak, like in > > > slides - http://www.iam.unibe.ch/~denker/talks/07ICOOLPS/07PICsICOOOLPS.pdf > > > paper - http://www.hirschfeld.org/misc/media/HauptHirschfeldDenker_2007_TypeFeedbac… > > For this design they just replace the pointer to the symbol in the > method's literal frame with a pointer to an object which then points to > that symbol and which also adds the needed information (class / compiled > method pairs). > > I plan to browse the Exupery sources to see what its PICs are like, but > for now I just took a quick look at the various presentations that are > available and saw a thread on this list from October 2008. My impression > so far is that PICs are short code fragments with pointers to classes > and which are treated mostly like native methods. > > If there are more details anywhere, it would be very helpful. > -- Jecel Exupery's PICs are still very simple. They are a short sequence of null instructions that are replaced with cmp reg class, je newMethod sequences. The PICs are made of two parts a control block with a little data describing the PIC and a single slot to record any interpreted classes. The profiler doesn't see primitives so the PIC records interpreted receivers so primitives from interpreted methods can be inlined. The PICs are only used for classes in old space. On a full GC they are all cleared and set back to all NULLs. The image can inspect them to see what classes they've seen. The only information stored is that the class has been seen. The PICs currently have room for three receivers, if they're full they overwrite the oldest entry. The code to populate the PIC is in exuperyPopulatePic:with:receiver: which is called by exuperySetup:Message:Send: Here's the send code sequence: (block 6 .... (mov (address block240) (8 ecx)) (mov 7 (12 ecx)) (mov eax (32 ecx)) (mov ebx (36 ecx)) (bitTest 0 eax) (jnc block241) (mov #(#specialObjectsOop) eax) (mov (24 eax) eax) ) (block243 (mov (picEntry -1313050144) ecx) (add 64 esp) (pop edi) (pop esi) (pop ebx) (mov ebp esp) (pop ebp) (pic eax) (push ecx) (mov 1 eax) (push eax) (push edx) (mov #exuperySetup:Message:Send: eax) (call eax) (mov esp ebx) (add 12 ebx) (mov ebx esp) (cmp 0 eax) (jz block239) (jmp eax) ) (block239 (mov 1 eax) (ret eax) ) (block241 (mov (eax) ebx) (sar 12 ebx) (and 31 ebx) (mov 0 ecx) (cmp ebx ecx) (je block242) (mov #(#specialObjectsOop) eax) (sub 1 ebx) (sal 2 ebx) (mov 4 ecx) (add ebx ecx) (add (116 eax) ecx) (mov (ecx) eax) (jmp block243) ) (block242 (sub 4 eax) (mov (eax) eax) (and 4294967292 eax) (jmp block243) ) In block 6 first the return address is saved into the context (stored in ecx here). Then the stack height is saved, it's tracked at compile time, then the arguments including the receiver are saved. Finally we check if the receiver is a SmallInteger, if it is then we load the class SmallInteger from the special objects array. Block 243 loads the picEntry, the control block for the PIC into ecx so that we can store it and the receiver if we fall through the PIC. It then pops out of the C stack enters the PIC, if the PIC falls through then it re-establishes the C stack frame, calls exuperySetup:Message:Send: which looks up the method using the same logic as the interpreter including using the interpreters message cache. The rest of the block and block 239 either returns to native code via "jmp eax" or returns back into the interpreter. Blocks 241 and 242 are decoding the receivers class. Block 241 is required because of compact classes. The PIC entries look like: (cmp eax classAddress) (je newMethod) Yes there's more than a few inefficiences here that could be removed with a bit of tuning. Bryce

1 0

Re: PIC details
by Igor Stasenko 05 Mar '09

05 Mar '09

I'm also interested. Especially, what statistical information need to be collected at call site to effectively switch between mono/poly/megamorphic cache. 2009/3/6 Jecel Assumpcao Jr <jecel(a)merlintec.com>: > I am interested in the various efforts to add Polymorphic Inline Caches > to Squeak, like in > >> slides - http://www.iam.unibe.ch/~denker/talks/07ICOOLPS/07PICsICOOOLPS.pdf > >> paper - http://www.hirschfeld.org/misc/media/HauptHirschfeldDenker_2007_TypeFeedbac… > > For this design they just replace the pointer to the symbol in the > method's literal frame with a pointer to an object which then points to > that symbol and which also adds the needed information (class / compiled > method pairs). > > I plan to browse the Exupery sources to see what its PICs are like, but > for now I just took a quick look at the various presentations that are > available and saw a thread on this list from October 2008. My impression > so far is that PICs are short code fragments with pointers to classes > and which are treated mostly like native methods. > > If there are more details anywhere, it would be very helpful. > -- Jecel > > _______________________________________________ > Exupery mailing list > Exupery(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery > -- Best regards, Igor Stasenko AKA sig.

1 0

PIC details
by Jecel Assumpcao Jr 05 Mar '09

05 Mar '09

I am interested in the various efforts to add Polymorphic Inline Caches to Squeak, like in > slides - http://www.iam.unibe.ch/~denker/talks/07ICOOLPS/07PICsICOOOLPS.pdf > paper - http://www.hirschfeld.org/misc/media/HauptHirschfeldDenker_2007_TypeFeedbac… For this design they just replace the pointer to the symbol in the method's literal frame with a pointer to an object which then points to that symbol and which also adds the needed information (class / compiled method pairs). I plan to browse the Exupery sources to see what its PICs are like, but for now I just took a quick look at the various presentations that are available and saw a thread on this list from October 2008. My impression so far is that PICs are short code fragments with pointers to classes and which are treated mostly like native methods. If there are more details anywhere, it would be very helpful. -- Jecel

1 0

Preparing for 0.15 and planning 0.16
by bryce＠kampjes.demon.co.uk 01 Mar '09

01 Mar '09

I'm doing the final preparation for the 0.15 release. There's a Linux VM and a Windows VM built so far. The Windows VM lacks freetype but should otherwise be OK, a proper Windows VM with Freetype would be nice especially as these VMs have Eliot's closure bytecodes in them.. I'll build an image in the next few days. The code on SqueakSource should be very close to the actual release code. There's no Mac VM. It would be nice if someone built one. I may add full method inlining in the next release, or at least an initial implementation. Inlining is a fairly simple feature except for blocks and de-optimisation. The problem with blocks is they can be accessed from external contexts so need to exist and can be returned to which complicates inlining them. The problem with de-optimisation is almost another blocks problem as de-optimisation needs to be thought about a little more carefully when de-optimising a method context may impact the execution of the block. The solution is probably to create contexts for both blocks and methods that create blocks. It'll make the inlined block situation a little slower but will make it possible to de-optimise one context at a time without risking crashes. Block contexts can always be removed if they're inlined from creation to execution, i.e. for the entire loop. The exact block inlining design doesn't need to be decided yet, it can wait until after the simple case of inlining a method into another method is implemented and debugged. Starting on full method inlining is a departure from plan. 0.15 looks solid enough to enable easy debugging of blocks. The original plan was to continue tuning for a 1.0 before adding full method inlining. the advantage of adding full method inlining now is it's a key part of the original design and will provide a large performance impact both in performance gains and also in changing relative costs. Bryce

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Exupery March 2009