Exupery December 2007

exupery@lists.squeakfoundation.org

3 participants
5 discussions

Compiler heuristics
by Igor Stasenko 28 Dec '07

28 Dec '07

It's a theoretical question, rather than practical concerning Exupery, but i'd like to know, what you know/thinking about special compiler heuristics concerning simplifying expressions, when do inlining. The problem, in basic can be demonstrated by following example. Suppose you having a code: mainMethod object = 0 ifTrue: [ object method1 ] ifFalse: [ object method2] and now method bodies: method1 object = 0 ifTrue: [ do something] ifFalse: [ do something else ] method2 object ~= 0 ifTrue: [ do something] ifFalse: [ do something else ] Now, the question is, when you inlining method1/2 into mainMethod you can see, that tests in inlined methods become redundant. If we inline both methods, code will look like: mainMethod object = 0 ifTrue: [ object = 0 ifTrue: [ do something] ifFalse: [ do something else ] ] ifFalse: [ object ~= 0 ifTrue: [ do something] ifFalse: [ do something else ] ] Is there any techniques, which can help in removing such redundancy, when analyzing code by compiler? -- Best regards, Igor Stasenko AKA sig.

2 4

Thinking about Exupery 0.14
by bryce＠kampjes.demon.co.uk 21 Dec '07

21 Dec '07

The primary goal for the next releases will be making the following benchmarks more compelling. I've added a compile time benchmark as there are a few performance bugs in the compiler that should be removed. arithmaticLoopBenchmark 1396 compiled 128 ratio: 10.906 bytecodeBenchmark 2111 compiled 460 ratio: 4.589 sendBenchmark 1637 compiled 668 ratio: 2.451 doLoopsBenchmark 1081 compiled 715 ratio: 1.512 pointCreation 1245 compiled 1317 ratio: 0.945 largeExplorers 728 compiled 715 ratio: 1.018 compilerBenchmark 483 compiled 489 ratio: 0.988 Cumulative Time 1125 compiled 537 ratio 2.093 ExuperyBenchmarks>>arithmeticLoop 249ms SmallInteger>>benchmark 1112ms InstructionStream>>interpretExtension:in:for: 113460ms Average 3155.360 First, I'll get the register allocator to allocate each section of method separately. After that, I'll probably do some work on further optimising the register allocator but I might work on improving the generated native code. Register allocating each section separately will both allow for better and faster allocation. It will make it easy to avoid dealing with registers and interference from other sections of the code and will reduce the size of the problem. Colouring register allocation written well should be on average n log n time but the performance bugs will raise that to probably n^2. It's possible that just allocating each section of the method separately will be enough to bring allocation down to a reasonable time. It should definitely help for the larger methods but is unlikely to do anything for the arithmaticLoop and will only help the bytecode benchmark slightly. Compiling quicker will make it easier to run more extensive tests. Bryce

2 4

[ANN] Exupery 0.13 Release
by bryce＠kampjes.demon.co.uk 12 Dec '07

12 Dec '07

Exupery 0.13 is released. This release is available from both the Universes and SqueakMap. A prebuilt image and the 0.12 VMs can be found from here: http://wiki.squeak.org/squeak/3945 This version has a few more bug fixes and some support to run Seaside. This release is reliable enough to use Seaside with. There's likely to still be bugs but it is reliable enough to play with or load during development. Either use Seaside 2.9 or the wbk version of Seaside 2.8. There's a minor change to continuations to make it easier to safely serialise them. Bryce

1 0

Preparing for Exupery 0.13
by bryce＠kampjes.demon.co.uk 10 Dec '07

10 Dec '07

Exupery now runs Seaside for over a few hours without crashing. It's time to release again. (1) I had Exupery and Seaside running for 12 hours on Sunday though only about 2-3 hours were using it solidly. This release will not need new VMs as there's been no VM changes. The next release will focus on speeding up compilation. The first step will be getting the register allocator to allocate each section of a method separately. Methods are often divided into many sections that are not connected as each message send exits the method then re-enters it. Register allocating each section separately should speed up register allocation, it will make allocation more accurate as it will ignore register interference in other sections, and it will make it easier to avoid loading context variables (including the stack) that are not used in that section. After register allocating each section separately it's debatable whether it will be better to continue optimising compilation speed as a few methods take several minutes to compile or to focus on speeding up the compiled code by avoiding loading unused stack variables and moving temporaries and arguments into registers. Making compilation faster seems like the best option because it will make testing faster which will speed up development and bug fixing. Bryce (1) You'll need to either use my version of Seaside 2.8 or Seaside 2.9. There's a tiny change required to continuations to allow Exupery to easily deoptimise contexts before they're serialised.

1 0

Seaside and Exupery patch
by bryce＠kampjes.demon.co.uk 04 Dec '07

04 Dec '07

I've placed Seaside2.8a1-wbk.523 on to the Seaside SqueakSource repository. This is a patch that moves the serialisation of contexts from Continuation into ContextPart. This is to allow Seaside to work with Exupery. Is it possible to get this merged into the development branch of Seaside? Yes, the latest development versions of Exupery will run Seaside, no, it's not yet practical. Expect bugs and don't expect a performance improvement yet. Bryce

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Exupery December 2007