Squeak People diary for willembryce

5 Oct 2008

Sun, 05 Oct 2008 18:37:16 -0700

An update on Exupery's progress

The three things that have been added since the last release are:

More x86 addressing modes

Generic primitives (calling out to the interpreter's primitives)

Eliot's closure bytecodes and Freetype support merged into the VM

More x86 addressing modes and generic primitives have helped out with performance.

The addressing modes help out in send/return code which accesses VM variables. Previously the address of the variable had to be loaded into a register, then that used to access it. Now it can be done in a single instruction.

Generic primitive support improves the number of cases Exupery can increase performance. If a primitive is called now that Exupery doesn't know how to compile, it can now dispatch to it via a PIC which is much faster than running through the interpreters lookup code.

Eliot's closure bytecodes have been merged in because the Pharo developers would like to start using them. I'd like to see proper closure support. At the moment the VM will run closure code but Exupery will not be able to compile it. That will take another VM change, and an Exupery compiler change to free up the "unused" slot in MethodContext.

The subpixel changes to bitblt have been merged into the VM, and the exupery-dev project on the Universes modified to load the packages required to build the FreeType plugin. I've got makefiles that work, they're not ideal but I ran into autoconf/automake issues that prevented using a better solution.

Also, I think I know what one of the remaining bugs is. When returning into compiled code from interpreted code the compiled context is not being marked as a root. Contexts are real objects, and need to keep the garbage collector book-keeping. Any objects in old space must be marked as roots if they point to new space. To avoid write barrier checks on context writes (all stack operations, and temporary assignments), all contexts are marked as roots if they're in old space when they're entered. Exupery's code does the marking in the return bytecode because there are less returns than points to return to. Every send, or potential send has an entry point, which is much more than the number of return bytecodes.

Next, I'll investigate this potential bug then fix it if it's real.

10 Aug 2008

Sun, 10 Aug 2008 11:52:37 -0700

Exupery now supports literal indirect addressing

The new benchmarks are:

arithmaticLoopBenchmark 490 compiled 100 ratio: 4.900
bytecodeBenchmark 857 compiled 299 ratio: 2.866
sendBenchmark 784 compiled 443 ratio: 1.770
doLoopsBenchmark 455 compiled 434 ratio: 1.048
pointCreation 498 compiled 506 ratio: 0.984
largeExplorers 181 compiled 185 ratio: 0.978
compilerBenchmark 278 compiled 271 ratio: 1.026
Cumulative Time 450.292 compiled 283.126 ratio 1.590

The overall ratio has increased from 1.54 to 1.59 and the compiler benchmark has increased from 0.98 to 1.03. The compiler benchmark is beating the interpreter again. It used to on the Athlon, but the Core 2 is much more efficient at running the interpreter.

What's happened to the code is sequences like:

(mov 2400 eax)
(mov #rootTableCount ecx)
(cmp eax (ecx))

are now:

(mov 2400 eax)
(cmp eax (#rootTableCount))

the optimal encoding would be:

(cmp 2400 (#rootTableCount))

There's still plenty of room to improve performance by improving instruction selection but the gains are likely to be smaller for each individual improvement.

Next up ^true, ^false, and ^ nil primitives. These only handle methods that just return true, false, or nil. Bytecodes are used to do ^ true from inside a method that does more work. These primitives exist to avoid creating a context for such trivial methods.

8 Aug 2008

Fri, 08 Aug 2008 23:26:29 -0700

Planning for Exupery 0.15

The two areas most in need of improvement before a 1.0 now are run time performance and reliability. Hopefully 0.15 will lead to a decent improvement in both. First runtime performance as the end of 0.14 involved a decent round of testing and debugging.

Here's some benchmarks:

  arithmaticLoopBenchmark  417 compiled  94 ratio: 4.436
  bytecodeBenchmark        725 compiled 262 ratio: 2.767
  sendBenchmark            692 compiled 403 ratio: 1.717
  doLoopsBenchmark         389 compiled 385 ratio: 1.010
  pointCreation            423 compiled 426 ratio: 0.993
  largeExplorers           198 compiled 199 ratio: 0.995
  compilerBenchmark        245 compiled 249 ratio: 0.984
  Cumulative Time          401 compiled 260 ratio 1.542

The primary goal is to improve the last two benchmarks, the two macro benchmarks. Both benchmarks use a profiler to decide what to compile, the goal is to compile enough methods to make a difference reasonably quickly so the benchmark doesn't take too long to run.

Here's the profile for compilerBenchmark:

CPU: Core 2, speed 3005.67 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000
Counted INST_RETIRED.ANY_P events (number of instructions retired) with a unit mask of 0x00 (No unit mask) count 100000
samples  %        samples  %        image name               app name                 symbol name
4122385  62.5654  4860169  58.3687  squeak                   squeak                   interpret
447635    6.7937  715498    8.5928  anon (tgid:6321 range:0xb1c91000-0xb7bf0000) squeak                   (no symbols)
224375    3.4053  412666    4.9560  squeak                   squeak                   exuperyCreateContext
157809    2.3951  269117    3.2320  squeak                   squeak                   exuperyIsNativeContext
126427    1.9188  230642    2.7699  squeak                   squeak                   allocateheaderSizeh1h2h3doFillwith
96316     1.4618  107350    1.2892  squeak                   squeak                   sweepPhase
87506     1.3281  47304     0.5681  squeak                   squeak                   lookupMethodInClass
53014     0.8046  71782     0.8621  squeak                   squeak                   markAndTrace
52262     0.7932  84112     1.0102  squeak                   squeak                   exuperySetupMessageSend
51999     0.7892  76301     0.9163  squeak                   squeak                   exuperyCallMethod
50920     0.7728  84568     1.0156  squeak                   squeak                   instantiateContextsizeInBytes
47231     0.7168  31047     0.3729  no-vmlinux               no-vmlinux               (no symbols)
42841     0.6502  52130     0.6261  MiscPrimitivePlugin      MiscPrimitivePlugin      primitiveStringHash
42560     0.6459  77447     0.9301  squeak                   squeak                   activateNewMethod

Only 14% of the time is going into code compiled by Exupery and it's helper functions. 62% of the time is still in the main interpreter loop. Interestingly the ratio between time in native code and time in exuperyCreateContext is the same as the send benchmark so it's likely that the native code is mostly in send processing. Either being called from interpreted code or sending to compiled code. The native code is executing 1.6 instructions per cycle, the CPU maxes out at 4 instructions per cycle.1.6 instructions per cycle would be excellent for an Athlon but Cores are more efficient, it's still good though.

Half of the time spent in exuperySetupMessage send is going to dispatching to unhandled primitives, the other half will be going to sends to interpreted code.

There's a few obvious things to do to improve performance:

Implement more addressing modes

Natively compile calls to C primitives

Implement the ^true, ^false, and ^ nil primitives

Remove jumps to jumps.

Implementing more addressing modes looks the most promising. It should speed up most of the benchmarks as all but the bytecode benchmark spend significant time in code that suffers badly from a single missing addressing mode especially object creation code and send/return code.

The current send optimisation is PICs which only work when sending from compiled code to compiled code. Sends to and from interpreted code are about the same speed or a little slower than interpreted to interpreted sends. It's true that this can be avoided by compiling more methods so most sends are compiled to compiled but it's much easier to decide what to compile if compiling anything is likely to lead to a speed improvement and not risk a speed loss.

Compiling the call to the primitive function into native code will allow the primitives to be dispatched via PIC instead of needing to go through exuperySetupMessageSend. Half of the calls to exuperySetupMessageSend in the compiler benchmark are for primitives, in the large explorers benchmark three quarters of the calls are for primitives. That time will disappear. Evaluating blocks uses a primitive send which takes a large proportion of the block dispatch time.

There's a handful of primitives that are implemented inside the main interpret loop. ^ true, ^ false, and ^ nil are some of them. They often show up when they fail to inline as Exupery can not yet compile them. If code uses them, then compiling it will cause a large time loss due to using a full primitive dispatch compared with the interpreter. Given how simple they are implementing them makes sense.

Exupery can create code that jumps directly to an unconditional jump. This does happen in some inner loops. The jumps should be modified to go to the target jump's destination. Jumping to a jump makes the CPU's front end's life difficult. In the compiler benchmark only for 9% of the time are the reservation stations full, which indicates that for most of the time the front end can not keep up with instruction execution.

Here's an example of the kind of code that's commonly generated with addressing mode problems. This example is from the method return sequence. Every compiled method goes through a block like this when returning:

  (block24
    (mov #nilObj eax)
    (mov (eax) eax)
    (mov eax (8 ecx))
    (mov #activeContext eax)
    (mov ebx (eax))
    (mov #youngStart eax)
    (mov #activeContext ebx)
    (mov (ebx) ebx)
    (cmp (eax) ebx)
    (jumpUnsignedGreaterEqualThan block25)
    (mov #activeContext eax)
    (mov (eax) eax)
    (mov (eax) ebx)
    (mov 1073741824 eax)
    (and ebx eax)
    (jnz block25)
    (mov 2400 eax)
    (mov #rootTableCount ecx)
    (cmp eax (ecx))
    (jumpSignedGreaterEqualThan block26)
    (jmp block27)
   )

The problem is instructions like "(mov #nilObj eax)" the address should be encoded in the memory access that uses it. There's no need to move an address into a register before using it. There's other problems besides not handling literal indirect addressing but the literal indirect problem is the largest.by a long shot.

I'm going to add literal indirect addressing first as it's harder to estimate what it'll do to overall performance but it is a problem for almost all the benchmarks.

It would also be worthwhile improving the profiling tools. It should be relatively easy to get oprofile to show the compiled method names instead of lumping all compiled code into the "anon" memory bucket. It would also be worthwhile and easy to write some code to read the oprofile files and compute the ratios rather than calculate them by hand.

30 Jul 2008

Wed, 30 Jul 2008 21:32:12 -0700

[ANN] Exupery 0.14 is released

The major improvement is to the speed of register allocation. I've fixed a couple of major performance problems so register allocation takes 50% of compilation time even for the largest methods. Register allocation now appears to take roughly linear time.

Installation instructions are here.

There's still plenty of room to improve compilation time. Every stage copies the entire intermediate graph to produce the input to the next stage which is redundant, most stages only change a few places. The register allocator's liveness analyser still uses Sets to represent which variables are live rather than bit vectors.

This release can compile cascades, the last missing core language feature. Exupery still can only compile a handful of the core primitives, it only compiles #at: for pointer objects. Cascades were added because they were used more in 3.10, the choice was either delete 2 system tests or add cascades. I delayed the release to add cascades.

There's a few bug fixes of old bugs but this release is not noticeably more reliable than the previous release. It should be a bit more reliable though, especially when running the new Exupery VM. The new Exupery VM just has a single bug fix in it.

Here's the benchmarks:

arithmaticLoopBenchmark 414 compiled 94 ratio: 4.404 bytecodeBenchmark 726 compiled 264 ratio: 2.750 sendBenchmark 707 compiled 454 ratio: 1.557 doLoopsBenchmark 388 compiled 398 ratio: 0.975 pointCreation 433 compiled 423 ratio: 1.024 largeExplorers 257 compiled 258 ratio: 0.996 compilerBenchmark 248 compiled 249 ratio: 0.996 Cumulative Time 419 compiled 275 ratio 1.519

ExuperyBenchmarks>>arithmeticLoop 105ms SmallInteger>>benchmark 362ms InstructionStream>>interpretExtension:in:for: 6051ms Average 612.691

The key benchmark for this release is the last one, compiling interpretExtension:in:for: which now only takes 6 seconds. With previous version of the compiler it used to take over 2 minutes to compile.

The change in times in the other benchmarks are mostly due to me upgrading from an Athlon 64 2.2GHz to a Core 2 3.0GHz. The register allocator should be slightly more efficient especially when compiling send heavy code.

Reliability and compile time performance has dominated the last few releases. Now run time performance and reliability are the biggest issues. Exupery still can crash after about an hour's active use depending on what's being done.

15 Jun 2008

Sun, 15 Jun 2008 21:41:40 -0700

Exupery update preparing for the 0.14 release

The Exupery 0.14 release is in final testing now. The major improvement is to register allocator performance. The register allocator should also produce slightly better code due to the changes. There's also now support for cascades, the last major missing language feature.

The main gain in this release is register allocation is much faster on large methods. Now it takes about 50% of the compilation time for all methods, it used to take almost all the time for large methods. This means compilation time is now roughly linear with method size.

The major improvements for 0.14 were done by mid April. The release has been delayed due to upgrading to 3.10. Exupery's testing uncovered two bugs in 3.10 and four tests were failing due to changes in the base image.

Two tests have been deleted as they were trying to compile methods that have been removed. Those methods were involved in bugs found by the stress test. There should be unit tests that cover any changes to the compiler required to fix them.

Two tests were failing because of cascades. Cascades have been added so they pass again. The other option was to either delete the tests or release with failing tests on 3.10.

All that's left to do before releasing is run the stress test again and do some Seaside development with Exupery running. Both were done successfully before upgrading to the latest squeak-dev 3.10 images.

3 Mar 2008

Mon, 03 Mar 2008 23:51:57 -0700

London Smalltalk Meeting this Saturday

The meeting is this Saturday. There's a good list of people attending, if you'd like to attend please add your name to the wiki page so building security will know to let you in.

If there's anything you'd like to present, please feel free to add your name to the list.

The wiki page is here.

Discussion and our monthly meetings are organised on the UK Smalltalk mailing list here.

18 Feb 2008

Mon, 18 Feb 2008 22:46:26 -0700

Reminder London Smalltalk Meeting Saturday 8th of March

There will be a Smalltalk meeting in London on Saturday the 8th of March. We plan to start at 10am with the morning focussed on beginners. Feel free to show up later, normally the afternoon will start around 1pm.

There's already about 20 people signed up on the wiki page, please add your name if you're interested in coming or presenting soemthing so building security will know to let you in.

RSPV required as it's being hosted in corporate offices.

Discussion or suggestions is best placed on the UK Smalltalk mailing list.

27 Jan 2008

Sun, 27 Jan 2008 12:03:24 -0700

Smalltalk UK meeting on Saturday 8th March

We're organising a Smalltalk event in London. This is going to be on a Saturday afternoon, we'll probably head to a pub afterwards. We'll aim to get a room with a projector.

Details are here. RSPV required as it's being hosted in corporate offices. Please add your name if you're interested in either attending or presenting.

Discussion will be on the UK Smalltalk mailing list.

3 Jan 2008

Thu, 03 Jan 2008 21:58:12 -0700

The next Saturday London Smalltalk Gathering

We're thinking about organising the next Saturday London Smalltalk gathering on the 8th of March. If there's any good reason to pick a better date please tell us before we start booking rooms. We'll aim to have a room with a projector so people can give talks. As always we'll probably migrate to a pub for dinner then a few beers afterwards

Discussion will be on the UK Smalltalk mailing list.

17 Dec 2007

Mon, 17 Dec 2007 22:47:48 -0700

Thinking about Exupery 0.14

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.