http://blog.gmane.org/gmane.comp.lang.smalltalk.exupery hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.lang.smalltalk.exupery/275 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 fo bryce< at >kampjes.demon.co.uk 2008-08-08T21:38:57 http://comments.gmane.org/gmane.comp.lang.smalltalk.exupery/274 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. 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 pre bryce< at >kampjes.demon.co.uk 2008-07-27T21:25:58 http://comments.gmane.org/gmane.comp.lang.smalltalk.exupery/273 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 we bryce< at >kampjes.demon.co.uk 2008-06-15T19:59:50 http://comments.gmane.org/gmane.comp.lang.smalltalk.exupery/270 in method addInterferenceEdge: firstRegister to: secondRegister is stumbled upon error: key not found when it does: secondNode := interferenceGraph at: secondRegister. an interferenceGraph keys = a Set(t9 t11 t14 t10 t2 t24 t22 t19 t25 t3 t8 t15 eax t20 t21 t16 t11 edx t17 t6 t3 t26 t12 t2 t4 t21 ecx t16 t12 t9 t23 t1 t5 t20 t13 t15 t14 t5 t27 t1 t6 t19 eax t13 t4 t17 t18 t28 t7 t8 t18 t10 t7) and secondRegister = eax. It looks like MedMachineRegister needs #= and #hash methods to make things working correctly with dictionaries. I'll try add these methods, lets see if issue will disappear. Btw, i don't know why or where it creates another instance of same register (MedMachineRegister name: #eax), in my code i using: 'machine registerNamed: #eax', which should create instance only once, and then return same instance for consequent calls. Igor Stasenko 2008-06-01T18:25:06 http://comments.gmane.org/gmane.comp.lang.smalltalk.exupery/262 I'm currently want to make an inlining for methods of specific format (lets call them 'native' methods), these methods should work as ST methods (same calling convention & stack layout when you entering method), but these methods don't do polymorphic sends unless specified exclusively, instead all sends are inlined statically with compiler. I don't want to describe much details here, just want you to help me how to deal with register spilling when inlining. Suppose i inlining a send like: object message: a+b with: c+d with: a+d with: .... so, all arguments to method now should use machine temporary registers instead of stack, because it's more effective. What i fear of that if register allocator sees that there is not enough registers in CPU to fit them all it starts using stack for storing temp values and there is some situations where i need to know exact stack depth for a method. Is there any way in Exupery to get know, how many registers will be spilled on stack, so this information can be used by my Igor Stasenko 2008-04-22T12:44:08 http://comments.gmane.org/gmane.comp.lang.smalltalk.exupery/258 I'm testing and debugging before the 0.14 release. The major benefit is faster compile times and better generated code. There's around a 10% gain or loss for the macro benchmarks depending on what's compiled. The bug was triggered by the below code. Originally it was compiling "^[42] value". The set-up shown below is what generates the fault without needing to compile the code. The fault was odd because it wasn't crashing, and wasn't stuck in an infinite loop but the image had locked up. I was investigating by interrupting execution with gdb and looking at both the Smalltalk stack using "p printCallStack()" and the C stack using "where". Normally, if compiled code was corrupting the object memory it would crash fairly quickly. That it kept executing, which could be seen because the Smalltalk stack kept changing was weird. If the GC's got a corrupt view of the object memory then normally it'll end up really corrupting it when it decides to try to interpret the middle of an object as an object header. Th bryce< at >kampjes.demon.co.uk 2008-04-20T09:38:45 http://comments.gmane.org/gmane.comp.lang.smalltalk.exupery/257 I've started the final release testing for Exupery 0.14. There are two bugs captured with tests so far. The first has something to do with interrupts, it needs a few running profilers to cause the bug to happen. I'm hoping this one is the source of the unrepeatable bugs that were in the the previous release, if so solving it may allow Exupery to run for much longer as a background compiler. The second bug is caused by the current work. What's happening is the currentContext register is being spilled but is being used by code generated in the register allocator to load the stack. It may also be needed by spill code to spill back into the stack. The simplest fix is to avoid spilling the currentContext. I doubt that spilling the currentContext is a good idea as it'll make spills of stack registers much more complex. Not spilling currentContext is probably the right thing to do unless the spill heuristics are improved to avoid spilling currentContext then spilling many stack registers that will use it to load bryce< at >kampjes.demon.co.uk 2008-04-12T21:40:47 http://comments.gmane.org/gmane.comp.lang.smalltalk.exupery/255 Hello Bryce, i'd like to ask you, how do you envision adding floating point support to Exupery to make it able to use FPU. The problem i see, is that it would require adding a type to registers to be able to use float-type values in intermediate code representation. Or else, how it would look like, when i need to encode floating point operations like: temp1 := floatValue1. temp2 := floatValue2. temp3 := temp1 + temp2. "here compiler should generate FPU instructions instead of integer addition" Or maybe i'm looking at problem at wrong angle? Maybe easier to make intermediate in format like: unaryFloatOp(argmunentAddress, resultAddress) binaryFloatOp(argmunent1Address, argument2Address, resultAddress) compareFloatsOp(arg1address, arg2address) then compiler don't have to deal with float registers (in register spilling code and other optimization patterns). Another thing, is support of byte-wide operations, like loading/storing byte at specific address. And of course being able to do some operations with Igor Stasenko 2008-03-16T13:05:06 http://comments.gmane.org/gmane.comp.lang.smalltalk.exupery/254 The next step after improving the spill heuristics is likely to be one of the following: * Spilling context registers directly to the context * Adding a few more primitives (String>>at: and return true, false, or nil) * More work on speeding up compilation * More bug chasing. There's two reasons to want to spill context registers directly into the context rather than onto the C stack. First it'll reduce memory traffic for sends with many arguments or a deep stack. At the moment the entire stack is copied from the context into registers when the method is entered (and possibly spilled on the C stack) then copied back onto the context on exit. For send heavy code this can lead to code that reads the stack into registers to immediately write it back out again. This is especially wasteful if that section of code doesn't use any of the stack variables copied. The second reason is to allow temporaries and arguments to be held in registers, if they're moved into registers then it's likely there will be mo bryce< at >kampjes.demon.co.uk 2008-01-08T20:02:26 http://comments.gmane.org/gmane.comp.lang.smalltalk.exupery/249 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, whe Igor Stasenko 2007-12-25T03:11:00 http://comments.gmane.org/gmane.comp.lang.smalltalk.exupery/244 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 probab bryce< at >kampjes.demon.co.uk 2007-12-17T21:50:31 http://comments.gmane.org/gmane.comp.lang.smalltalk.exupery/243 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 bryce< at >kampjes.demon.co.uk 2007-12-12T21:03:34 http://comments.gmane.org/gmane.comp.lang.smalltalk.exupery/242 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 minut bryce< at >kampjes.demon.co.uk 2007-12-10T21:08:04 http://comments.gmane.org/gmane.comp.lang.smalltalk.exupery/236 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 Rob Withers 2007-11-17T20:14:56 http://comments.gmane.org/gmane.comp.lang.smalltalk.exupery/231 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 bryce< at >kampjes.demon.co.uk 2007-10-28T22:05:40 http://comments.gmane.org/gmane.comp.lang.smalltalk.exupery/226 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 bryce< at >kampjes.demon.co.uk 2007-10-25T21:11:12 http://comments.gmane.org/gmane.comp.lang.smalltalk.exupery/225 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 bryce< at >kampjes.demon.co.uk 2007-10-25T20:24:35 http://comments.gmane.org/gmane.comp.lang.smalltalk.exupery/221 ESUG saw a lot of progress for Exupery. There is now a preliminary Mac port and 2 bugs were fixed. There is a Mac VM available here: http://wiki.squeak.org/squeak/3945 This version is compiled without optimisation. It looks like there's a bug in GCC 4.0.1 which is preventing sends from working in Exupery. Exupery works fine with gcc 3.3.3 and gcc 4.1.2. Hopefully there will be a more polished Mac VM soon compiled with optimisations. Thanks to Matthieu for building this. Two bugs were fixed. The major bug was due Exupery overflowing the root table, this was the one that was causing the crashes that I was debugging. There was a minor bug that was due to failing to mark Exupery's interpreter integration objects which as far as I'm aware has never caused a crash, it's fixed too. I'm starting to think about the next release seriously as I'm hopeful that it's only one bug fix away. The pre-release tasks are: * Fix the current bug * Test that Exupery can compile in the background for an hour * Check tha bryce< at >kampjes.demon.co.uk 2007-09-04T08:45:17 http://comments.gmane.org/gmane.comp.lang.smalltalk.exupery/220 I've added a new article about Exupery's design and direction to Exupery's bibliography. It's the last link on this page: http://wiki.squeak.org/squeak/5792 Bryce bryce< at >kampjes.demon.co.uk 2007-08-19T15:53:35 http://comments.gmane.org/gmane.comp.lang.smalltalk.exupery/215 _______________________________________________ Exupery mailing list Exupery< at >lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery Jason Johnson 2007-08-04T09:11:19 http://comments.gmane.org/gmane.comp.lang.smalltalk.exupery/206 _______________________________________________ Exupery mailing list Exupery< at >lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery J J 2007-07-24T16:55:16 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.smalltalk.exupery