Exupery 0.11rc1 is out

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Exupery 0.11rc1 is out

Bryce Kampjes

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
Reply | Threaded
Open this post in threaded view
|

Re: Exupery 0.11rc1 is out

Andrew Gaylard
On 2/14/07, [hidden email] <[hidden email]> wrote:

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?

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
Reply | Threaded
Open this post in threaded view
|

Re: Exupery 0.11rc1 is out

Andrew Tween
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
Reply | Threaded
Open this post in threaded view
|

Re: Exupery 0.11rc1 is out

Bryce Kampjes

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
Reply | Threaded
Open this post in threaded view
|

Re: Exupery 0.11rc1 is out

Bryce Kampjes
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