Exupery

exupery@lists.squeakfoundation.org

107 discussions

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

Speedup from Exupery for SqueakElib
by Rob Withers 19 Nov '07

19 Nov '07

Hi All! I have reached step 2.4 in my SqueakElib plan documented here: http://wiki.squeak.org/squeak/6011, but I don't know anything about Exupery. I suppose my first question is whether I am right in assuming that I will see speedups if I incorporate Exupery? My next question is related to the work I did in steps 1.3, 1.4, and 1.5. I modified the VM to use larger contexts (80+7), to add extra long jump bytecodes for jump:, jumpIfTrue: and jumpIfFalse:, and to add bytecodes for doing receiver class tests. Will these additions cause problems with Exupery? If all is ok so far, I want to build my modified Windows VM with Exupery, so I am reading http://wiki.squeak.org/squeak/5904. I am confused as to which VMMaker I can use to build. I currently have VMMaker-tpr.58.mcz loaded. Can you confirm that I need to either overwrite this VMMaker with the one from the Exupery repository or that I need to build fresh with the one from the Exupery repository? Also, where is the VMMaker from the Exupery repository - where is the Exupery repository? Finally, what is the best Subversion client for Windows and how do I connect to this Exupery repository? Thanks and Cheers, Rob

2 2

[ANN] Exupery 0.12 release
by bryce＠kampjes.demon.co.uk 04 Nov '07

04 Nov '07

This release * Has a background compiler that can be run for about a hour * Has many bug fixes * Merges in David and John's 32 bit clean work and makes Exupery 32 bit clean. Installation instructions and links to VM's and pre-built images are here: http://wiki.squeak.org/squeak/3945 To use the background compiler: First initialise Exupery to prepare the code cache. This will also clear out any currently compiled code. Exupery initialiseExupery Then start the background compiler using the following expression. Exupery startBackgroundCompilation. Then when done use the following to stop it. Exupery stopBackgroundCompilation. Thanks to Andy Tweek and Mathieu Suen for building the Windows and Mac VMs. The Mac VM was built with gcc optimisation switched off to avoid a bug in gcc 4.0 so it's probably much slower than the normal VM. This is still an alpha release, running the background compiler will lead to crashes, but it should run for long enough to play with. The next release will improve both the profiler that drives background compilation and reliability. Bryce

1 1

Exupery 0.12 release progress
by bryce＠kampjes.demon.co.uk 30 Oct '07

30 Oct '07

We've a Windows VM thanks to Andy. There's an Linux VM and a pre-built Exupery development image. There's also entries in SqueakMap and Package Universes. Links to the pre-build items are here: http://wiki.squeak.org/squeak/3945 The Package Universes Exupery Development package doesn't fully work. To use it load CommandShell from SqueakMap after loading it. This is because GraphViz needs the latest CommandShell which hasn't yet made it to universes. I've emailed Lex to get this sorted. Bryce

2 2

Preparing for Exupery 0.12
by bryce＠kampjes.demon.co.uk 28 Oct '07

28 Oct '07

I've decided to release what I've got. There's more than enough in this release to justify releasing. The background compiler now runs for about a hour. It'll still need some work before it is practical, that's probably next. This release * Has a background compiler that can be run for about a hour * Has many bug fixes * Merges in David and John's 32 bit clean work and makes Exupery 32 bit clean. Andy, when can you build a Window's VM? Mathieu is planning on building a Mac VM. To use the background compiler: First initialise Exupery to prepare the code cache. This will also clear out any currently compiled code. Exupery initialiseExupery Then start the background compiler using the following expression. Exupery startBackgroundCompilation. Then when done use the following to stop it. Exupery stopBackgroundCompilation. Bryce

2 2

Planning Exupery 0.13
by bryce＠kampjes.demon.co.uk 26 Oct '07

26 Oct '07

My current plan for 0.13 is: * Get background compiler to ignore methods that failed to compile * Don't flush the code cache on every class change * Fix more bugs * Add some instrumentation to get quantitative information on time spent compiling and the percentage of time spent in compiled code. The goal is to make the background compiler practical. It will still be limited due to missing features slowing down compiled code and slow compile times. A test would be to run the background compiler until Exupery was compiled then to start playing with tinyBenchmarks and to see the improvement as it compiles the methods and inlines the primitives. Currently the background compiler doesn't avoid methods that have failed to compile once. This is a problem as the compilation queue could get full of methods that don't compile blocking compilation of methods that do compile. Flushing the code cache on every class change is overkill. It also reduces the value of some of the acceptance testing as it can't effectively test compiling tests that change classes and several do. It would be nice if Exupery reported the percentage of time spent in compiled code to gauge how well the background compiler was doing. I can measure this using oprofile but not in Squeak. It would also be nice if Exupery recorded how long a method took to compile to gauge how much of a problem compilation speed currently is. It would be nice if Exupery recorded why methods failed to compile so it was easy to figure out how important adding the remaining missing features is. The other possibility for 0.13 would be to optimise compilation time. There are a few methods that take minutes to compile due to known performance bugs in the register allocator. Increasing the speed of the compiler will both make compilation more practical and make it cheaper to compile more code in tests. The third major thing required before a 1.0 would be to implement cascades and a few more bytecodes. This should allow Exupery to optimise more code successfully. This is aiming to optimise run time performance. I'm not considering this for 0.13 but is needed before 1.0. Bryce

2 2

Changing the names of all conditional branches
by bryce＠kampjes.demon.co.uk 07 Oct '07

07 Oct '07

I'm making Exupery 32 bit clean. This should help when running on OSes that like to place the image across the 2 Gig boundary or above it. As part of this I'm renaming the conditional jumps from names like jl, jle, and jg to jumpSignedLessThan, jumpSignedLessEqueals, and jumpSignedGreaterThan. This is so that it's easy to see what's using signed or unsigned comparisions. The 32 bit clean bugs are caused by using signed comparisions when the sign changes or is negative and we should be using unsigned comparisions. By renaming the conditional jumps it should be easy to keep such bugs out as it'll be easy to see what's signed or unsigned. Aso the longer names seem to make more sense when we're only occasionally dealing with that intermediate. The original names were taken from the x86 instruction set. Bryce

1 0

← Newer
1
2
3
4
5
6
7
...
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Exupery