Exploring an alternative bytecode set

Florin X Mateoc mateoc_florin at jpmorgan.com
Wed Nov 10 16:27:09 UTC 1999


I have enjoyed your presentation at OOPSLA and I think it is a very good idea. I
am not sure that you need to change the bytecode set for it though. Perhaps I
missed the point but to me the idea is similar to compression, where by encoding
groups of symbols instead of the symbols themselves you can achieve a much
better compression rate. This could translate into interpreting groups of
bytecodes at a time instead of the bytecodes directly, but then only the
interpreter needs to change, not necessarily the bytecode set.
The reason why I think such an approach would be better is that I heard Elliot
pleading for a unified bytecode set across Smalltalks (followed by a second
round of ANSI standardization), and my impression was that Squeak central seamed
interested and to me it seams like a very valuable goal. This could mean a
second (Nth ?) youth for Smalltalk.

Florin





janb at pmatrix.com on 11/10/99 12:01:36 AM

Please respond to squeak at cs.uiuc.edu

To:   squeak at cs.uiuc.edu
cc:   (bcc: Florin X Mateoc)
Subject:  Exploring an alternative bytecode set




I received quite a bit of positive feedback at OOPSLA on my alternative
bytecode set and am starting to consider what it might take to hook it into
Squeak. The theory is 2x-3x better interpreter performance could be
achieved with different bytecodes. I'm rather interested in determining how
correct this theory is. It's not real clear how much work this would be or
how much time I would have available.

It seems like taking the path of minimum work would increase the chances of
something getting delivered, even if it meant giving up some performance
initially. I'm looking for some feedback from Squeak Central (and anybody
else doing alternative bytecode set's) on any upcoming changes in the VM. I
suppose the biggest upcoming change may be Jitter V3. Does improving the
bytecode interpreter performance even make sense at this point? The sense I
got at the workshop and Squeak BOF was that keeping an implementation
simple was a desirable goal for many people, so keeping an interpreter
available was also desirable. Serious fooling with the interpreter might be
better timed 6-12 months from now though, when Jitter integration calms
down a bit.

My thought is changing the bytecode set would involve:

1) Some research/analysis on different platforms using test programs, to
understand some design tradeoffs on different processors.

2) Write a new interpreter simulator class for the new bytecode set

3) Make a new compiler version that could generate the new bytecode set

4) Clone an image, recompiling all methods to the new bytecode set

5) Run the cloned image as a simulation

6) Write a new interpreter class to move from simulation to execution

Some unknown areas seem like:

1) Running methods in multiple bytecode sets would be very desirable

2) How much work would it take to change Jitter V3 to a different bytecode set.

3) Impact of bytecode set changes on things like execution context format
and gc.

So what do people think about this? I'm a bit concerned about distracting
everybody from Ian's very excellent Jitter work. Or maybe Ian and others
would get even more creative about fast native execution if ground level
calibration was moved up. Anybody know what kind of dynamics motivated the
Self team to deliver their performance miracles? Was it one guy (or gal)
and a large bottle of brain enhancing chemicals? Or a friendly little
battle of my VM's faster than your VM? Or "Oh my god", if I don't get this
thing to go fast I won't get my degree.

I'm always interested in what causes peak performance states in people. At
OOPSLA DaveU said showers did it for him. For me, extending that half awake
half asleep state in the morning is my creative playground (ring...yes Mr.
Manager, I'm working on that very tricky problem right now, please go away
and let me get back to dreamland where I can get some work done...)

- Jan





More information about the Squeak-dev mailing list