[BC] Block Closures, Version 2

Scott A Crosby crosby at qwes.math.cmu.edu
Thu Feb 14 13:31:46 UTC 2002


On Thu, 14 Feb 2002, Anthony Hannan wrote:

> On the BC page (http://minnow.cc.gatech.edu/squeak/BlockClosureVersion)
> you will find a new BC version.  Its image format is slightly different
> from the last version, so you need a new VM and image.  But this new VM
> interprets bytecodes 20% faster and message sends 50% faster than the
> standard VM according to 0 tinyBenchmarks on my i586 533MHz Linux
> machine (the old BC version was only 10% and 33% faster).  Also, I fixed

Sweet... Hey, I've got some profiling that is now indicating that the
interpreter is actually starting to spend serious time (a few PERCENT!!)
just pushing self and local variables from the stack, which is good news.

It indicates that the bytecode main loop is actually starting to suck a
non-apreciable amount of time, which means that everything else is going
extremely well.

Does BC v2 makes those cheaper, due to the using a cheaper stack?

>
> Of course, I encourage interested parties on other platforms to build
> VMs and post them on the BC page.  I would also be interested in
> combining other VM enhancements (hey Scott) and posting them in a
> different section on the page.

Anyways, what are you asking for?

1. For me to do a quick check to see if integration can be done easily?
2. For me to keep (and maintain) an updated patch for BCv2, until BCv2 has
   stabalized, then integrate it into the image.
3. For me to create a patch thats ready for the current version, integrate
it now, and be done with it?
4. For me to do nothing, then when BCv2 is ready for integration, I update
the patch and install it then?

I already tested out #1, so I don't see much reason in repeating that
work. For #2, not desireable, I have some bad-news on that front.
(forthcoming). For #3 or #4, I'm willing to do either at any time.

I'm willing to do this for the root table overflow and new methodcache
patches.

Scott

[*] I have a list of other things that should be considered for
inclusion in the VM. Also forthcoming.




More information about the Squeak-dev mailing list