I'm finishing up the 0.11 release. It should be both more reliable and more functional than 0.10. There are known bugs but they only stop methods from being compiled. They don't cause crashes or incorrect code. This release includes: * A #new and #@ primitive for fixed size pointer objects. * A class for compiled methods that provides better debugger support. * Interrupt checking from compiled code so Alt-. will work. This should include all the VM and compiler work required to allow methods to be compiled in the background safely. That's the goal for 0.12. I'm thinking about scripting building an Exupery development image. The development tools use GraphViz to layout the method's control flow graphs in inspectors. Also the tests can rely on external packages, this is normally when the test was created to capture a bug. I've had a look at Andrew's VM building script. It would be nice to automate the set-up of a VM building environment. Though, I'd rather have it scripted from Smalltalk than from shell. Would it be worthwhile adding the shell script to a class side method as executable documentation? It would be nice to have a Windows VM for this release. Bryce _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
On 2/14/07, [hidden email] <[hidden email]> wrote:
Hi Bryce, By all means feel free to use my script as documentation. However, be warned that it doesn't work yet! What I sent was a first pass, to see if there was interest from the rest of the Exupery community, and to get some feedback (thanks, BTW). (I've been ill for a while now, so there hasn't been much progress on the script, but I am planning to get back to it.) I'm keen to have a way building an Exupery image starting only with the basic bits: the VM source, a vanilla (released) image, etc. The reason for this is that I'm keen to try porting Exupery to other CPUs, and this seemed like a good starting point. Also, I feel that being able to recreate the whole Exupery environment (VM + image) would lower the barrier to entry for others who might be interested in working on the compiler. As a rule, I try to build images from scratch where possible, to know exactly what went into them, in what order; using a program to build them automates the whole process nicely. I feel that making Exupery able to target many CPUs might shake out some latent bugs (alignment, endianness, word-size, ABI, and so on). And I have various machines for testing: x86, SPARC, HPPA, Alpha, and ARM, giving a good mix of LE/BE and 32-/64-bit. Anyway, by all means replace the shell script with Smalltalk if you feel that's the way to go. Initially, I felt that shell was a better starting point (configure, make, make install, etc), but as I looked more & more at all the bits I needed to add to the image, I started to realise that the Smalltalk section inside the script would probably exceed the shell bits by a good percentage, making Smalltalk a better choice for the job. Andrew. _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
In reply to this post by Bryce Kampjes
Hi Bryce,
Nice to see you making such good progress. <snip> > It would be nice to have a Windows VM for this release. I've built a new Windows VM based on the latest one released by Andreas a couple of weeks ago. I'll zip and mail it to you. I used these packages (let me know if I used the wrong ones). VMMaker-wbk.66.mcz Exupery-wbk.241.mcz There were 4 failures in the story tests - all due to missing classes. Here are the benchmarks... arithmaticLoopBenchmark 2358 compiled 361 ratio: 6.532 bytecodeBenchmark 4184 compiled 1433 ratio: 2.919 sendBenchmark 3342 compiled 1919 ratio: 1.742 doLoopsBenchmark 2111 compiled 1851 ratio: 1.140 pointCreation 3079 compiled 2503 ratio: 1.229 largeExplorers 1755 compiled 1406 ratio: 1.248 compilerBenchmark 1315 compiled 1268 ratio: 1.036 Cumulative Time 2426.005 compiled 1350.650 ratio 1.796 Cheers, Andy _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
Thanks Andy, I've uploaded the VM you supplied. It's really nice to be able to release with a VM for two major platforms at the same time. The versions you used are correct and your benchmarks look fine. Here's the benchmarks I get on a AMD 64 3500 (2.2GHz): arithmaticLoopBenchmark 1387 compiled 127 ratio: 10.920 bytecodeBenchmark 2139 compiled 484 ratio: 4.419 sendBenchmark 1582 compiled 728 ratio: 2.173 doLoopsBenchmark 1063 compiled 843 ratio: 1.261 pointCreation 1075 compiled 1030 ratio: 1.044 largeExplorers 585 compiled 595 ratio: 0.983 compilerBenchmark 474 compiled 454 ratio: 1.044 Cumulative Time 1058.337 compiled 521.541 ratio 2.028 It's nice that you're getting better numbers for pointCreation and largeExplorers than I am. On my machine the interpreter is doing very well at object creation. When I first investigated the interpreter was much slower, I don't know why it's gotten faster but I've changed VMMaker versions, compiler version, and CPU since then. That said, this release is slower than the previous releases for most things. That's because it now checks for interrupts on message entry and backwards jumps. I haven't done any tuning since adding the interrupt checks. The goal for now is to provide a practical speed improvement. Bryce Andrew Tween writes: > Hi Bryce, > Nice to see you making such good progress. > > <snip> > > It would be nice to have a Windows VM for this release. > > I've built a new Windows VM based on the latest one released by Andreas a couple > of weeks ago. > I'll zip and mail it to you. > > I used these packages (let me know if I used the wrong ones). > > VMMaker-wbk.66.mcz > Exupery-wbk.241.mcz > > There were 4 failures in the story tests - all due to missing classes. > > Here are the benchmarks... > > arithmaticLoopBenchmark 2358 compiled 361 ratio: 6.532 > bytecodeBenchmark 4184 compiled 1433 ratio: 2.919 > sendBenchmark 3342 compiled 1919 ratio: 1.742 > doLoopsBenchmark 2111 compiled 1851 ratio: 1.140 > pointCreation 3079 compiled 2503 ratio: 1.229 > largeExplorers 1755 compiled 1406 ratio: 1.248 > compilerBenchmark 1315 compiled 1268 ratio: 1.036 > Cumulative Time 2426.005 compiled 1350.650 ratio 1.796 > > Cheers, > Andy > > > > _______________________________________________ > Exupery mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
In reply to this post by Andrew Gaylard
Hi sorry about the delay in answering this, more below. Andrew Gaylard writes: > > Hi Bryce, > > By all means feel free to use my script as documentation. > However, be warned that it doesn't work yet! What I sent was > a first pass, to see if there was interest from the rest of the > Exupery community, and to get some feedback (thanks, BTW). I've decided not to include the script in the release though the process of setting up VM building environments definitely needs some work. The VM build problems are shared with the main interpreter, ideally any solution we adopt for Exupery should be acceptable for the normal VMs too. > I'm keen to have a way building an Exupery image starting > only with the basic bits: the VM source, a vanilla (released) > image, etc. The reason for this is that I'm keen to try porting > Exupery to other CPUs, and this seemed like a good starting > point. Also, I feel that being able to recreate the whole > Exupery environment (VM + image) would lower the barrier > to entry for others who might be interested in working on the > compiler. > > As a rule, I try to build images from scratch where possible, > to know exactly what went into them, in what order; using a > program to build them automates the whole process nicely. A basic Exupery image should be just the base image with Exupery loaded. There's no reason for other dependencies. There is currently a dependency on VMMaker for a class extension method. The other dependencies are just classes some of the tests use. Those tests were created to capture bugs. > I feel that making Exupery able to target many CPUs might > shake out some latent bugs (alignment, endianness, > word-size, ABI, and so on). And I have various machines > for testing: x86, SPARC, HPPA, Alpha, and ARM, giving a > good mix of LE/BE and 32-/64-bit. It would definitely be great to have a CPU port. I'd either try to do a 32 bit port or port to AMD64. Exupery should be portable but there's a few details that are not yet well encapsulated including the C calling conventions used both to enter Exupery from the interpreter and to call helper functions. There are two separate images available for 64 bit Squeak. One can run 32 bit images and the other runs 64 bit images. Running a 32 bit image on a 64 bit machine requires all memory access to be indirected through a base pointer. Exupery doesn't deal with bytes directly so byte endianness is probably not an issue yet but it also doesn't separate out addressing operations which would be 64 bits from slot accessing which could be 32 bits. Given that, it would make sense to start either the easiest possible 64 bit port, or do a 32 bit port. To do a port you'd just need to get the VM building on the platform you want to port to. More VM building work would be nice but not required. Squeak's ported to many platforms, ideally any build automation should be at least as portable as Squeak. Bryce _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
Free forum by Nabble | Edit this page |