Common Smalltalk VM Summit

> Hi everybody,
>
> Dan Ingalls and I have been talking, trying to figure out what to do about
> the major opportunity offered by the recent release of the Strongtalk
> virtual machine as open source.
>
> Rather than keep this discussion to ourselves, our thinking was that this
> would be the perfect time to call a kind of summit, with representatives of
> all the major Smalltalk implementations, both open-source and commercial.
> The topic: what if we could build a shared high-performance open-source
> platform suitable for hosting a number of different Smalltalk systems, one
> that we can all share and work on together?

> While the details of the type-feedback techniques used in the Strongtalk VM
> are arcane, the benefits are not: *much* higher performance for general
> Smalltalk code.  Dan, myself, and many others who know about type-feedback
> and the pioneering Self system, have been dreaming for many years about the
> possibility that someday this technology might make it into mainstream
> Smalltalk VMs.  It would take Smalltalk performance to a whole new level.
>
> That someday is here now, if the different factions within the Smalltalk
> community can pull together a little bit so that we don't miss this
> opportunity.

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of
> [hidden email]
> Sent: Thursday, October 05, 2006 5:41 AM
> To: The general-purpose Squeak developers list
> Subject: Re: Common Smalltalk VM Summit
>
>
> Hi David and all!
>
> Some ramblings from a non VM hacker:
>
> "David Griswold" <[hidden email]> wrote:
> > Hi everybody,
> >
> > Dan Ingalls and I have been talking, trying to figure out what
> to do about
> > the major opportunity offered by the recent release of the Strongtalk
> > virtual machine as open source.
> >
> > Rather than keep this discussion to ourselves, our thinking was
> that this
> > would be the perfect time to call a kind of summit, with
> representatives of
> > all the major Smalltalk implementations, both open-source and
> commercial.
> > The topic: what if we could build a shared high-performance open-source
> > platform suitable for hosting a number of different Smalltalk
> systems, one
> > that we can all share and work on together?
>
> Question #1: Will you and/or Dan be at OOPSLA now in October?
>
> > While the details of the type-feedback techniques used in the
> Strongtalk VM
> > are arcane, the benefits are not: *much* higher performance for general
> > Smalltalk code.  Dan, myself, and many others who know about
> type-feedback
> > and the pioneering Self system, have been dreaming for many
> years about the
> > possibility that someday this technology might make it into mainstream
> > Smalltalk VMs.  It would take Smalltalk performance to a whole
> new level.
> >
> > That someday is here now, if the different factions within the Smalltalk
> > community can pull together a little bit so that we don't miss this
> > opportunity.
>
> A few comments:
>
> IMHO there are at least two very interesting projects in this arena:
> Ian's pepsi/coke/idst and Bryce's Exupery.
>
> It was a while since I heard anything about AoStA. And all the "other"
> non-Smalltalk projects like Parrot, YARV (a fast Ruby VM - tons of those
> projects apparently), Pypy etc are probably too far "away" from the
> Smalltalk community to be of real interest.
>
> Then of course we have Spoon - the "minimal Squeak project" that Craig
> is pulling - which probably could form a very good new "kernel image" on
> top of a new VM, but despite some low level modification to the VM like
> his super proxies etc - he has AFAIK not yet touched the VM much.
>
> Now, to most of us Squeakers it is joyful to see Strongtalk "back in
> business" - especially since that includes people like you. :)
>
> On the other hand, a big chunk of C++ doesn't really sound like an
> attractive artifact - at least not to me ;). Ian has moved away from C++
> as his choice of VM implementation platform (see idst/pepsi/coke etc)
> and Bryce is building Exupery entirely in Squeak itself.
>
> Getting the whole (including commercial ones) Smalltalk community united
> behind a common execution platform is probably... hard. But getting the
> open source subset of the Smalltalk community (GST, Squeak and so on)
> united should be at least in the realm of possibilities.
>
> Without actually knowing what I am blabbering about I would *love* to
> see the following happening:
>
> You (and other Strongtalk implementors) take your expertise (and
> possibly even code) and take a hard look at Ian's and Bryce's work and
> join up with them.
>
> Exupery is probably the "backwards compatible" (since it more or less
> piggy backs on the existing VM which is quite polished at this time) way
> to real speed for the current Squeak VM in a reasonable timeframe.
>
> But pepsi/idst/coke looks to me to be perhaps the most promising and
> exciting low level platform ever. I am hoping that Exupery can somehow
> eventually become a part of that, as one of several backends - and I am
> also betting that Ian has the ambition to include type-feedback
> optimizations into it.
>
> Since pepsi/idst/coke is so malleable (it is not even a VM!) it seems
> like it could have a chance to become a common platform for different
> Smalltalks - it is meant to work for almost any kind of language, and
> already has other languages running on top of it - like javascript (in
> some form).
>
> Well, there are others with much more insight than little me. But to be
> frank - I don't see lots of Squeak VM experts rushing over to try to
> grok a large C++ code body. I do however see people flocking towards
> Exupery (since it is written in Smalltalk) and to pepsi/idst/coke (since
> it too is written in Smalltalk to a large degree).
>
> So not to put a damper on the enthusiasm here (which I probably did
> anyway - but that is not my intention) but I think that the
> Strongtalkers should join the Squeakers - and not hoping for the
> opposite to happen. ;)
>
> regards, Göran
>
>
> PS. These are exciting times for Smalltalk. Let's have fun no matter
> what! An appetizer to get you all interested in idst/pepsi/coke, have
> you *ever* seen a Smalltalk hello world like this?!:
>
>

> Ok everybody,
>
> Hopefully the right people are listening in so that we can have a real
> dialog between the different Smalltalk implementations.
>
> Basically what I am proposing is that we try to join efforts to  
> support an
> open source high-performance VM that we could all then use however  
> we want.
> No one Smalltalk faction could do this before, because building a
> type-feedback VM from the ground up is just too big a job for a  
> small group
> of volunteers, especially if they didn't have experience with the  
> Self VM,
> on which it is based.  But now we have one that is basically done,  
> with just
> some debugging and tweaking here and there, which is a lot less  
> effort than
> writing a new one.
>
> I'm not proposing that we all give up our different Smalltalk tools,
> libraries, GUIs, etc.  In fact, hopefully this could be done  
> without anyone
> having to commit to tossing their own VM out.  The idea would be to  
> factor
> out a core VM interface, and then each platform could wrap that as  
> necessary
> to make it look the way their libraries expect it to.  Then there  
> would at
> least be the option of plugging in a different VM, and if people  
> like it,
> they could then switch to it completely if they want.
>
> Of course, this requires compromising on all sides, since there are  
> numerous
> small language and VM functionality differences we would have to  
> iron out.
> But even if there is some pain there, the benefit of having a common
> language semantics and a bigger group of people supporting the VM  
> should be
> worth it.  It might even be a path, eventually, to reuniting the  
> Smalltalks.
> For commercial Smalltalks, one big benefit would be the increased  
> comfort
> that customers would have because the VM would be open source, and  
> thus more
> likely to survive in the long term.
>
> I'm not saying that I or Strongtalk would even have to play the  
> leading role
> here.  There are plenty of smart VM people in the Smalltalk  
> community, and
> they are welcome to step up and assert themselves.
>
> We need to look more closely at the various VM and language  
> differences that
> we would have to overcome.  What is everyones feedback on the  
> difficulties
> and benefits of doing this?
>
> -Dave
>
>
>

>From: "David Griswold" <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: "The general-purpose Squeak developers
>list"<[hidden email]>
>Subject: RE: Common Smalltalk VM Summit
>Date: Thu, 5 Oct 2006 09:29:23 -0700
>
>- I am a fan of things like Exupery etc.  But I don't think it is
>reasonable
>in the near future to retrofit type-feedback into any of the existing VM
>frameworks.  If it was that easy it would already have been done.  The
>type-feedback infrastructure needs to be built in from the beginning.
>Without that infrastructure, no compiler will even get close to the
>performance of type-feedback on general Smalltalk code (as opposed to
>microbenchmarks).
>
>Dave
>

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of
> Michael Haupt
> Sent: Friday, October 06, 2006 10:33 AM
> To: The general-purpose Squeak developers list
> Subject: Re: Common Smalltalk VM Summit
>
>
> Hi,
>
> On 10/6/06, J J <[hidden email]> wrote:
> > I'm confused.  I thought type-feedback wasn't going to give and speed
> > improvements.  If not, then what does it buy?
>
> it's the optional type system in Strongtalk that does not improve
> performance. Type *feedback* does, though.
>
> Take Self, for example. It does not have a type system (not even an
> optional one), but type feedback-directed optimisation. Type feedback
> works without a "static" type system backing it.
>
> The type feedback mechanisms are - provided I understand them
> correctly - about recording type information at send sites. This can
> be done in the absence of actual type annotations as well as in their
> presence. The latter approach is the one Strongtalk follows: type
> declarations are a "helping hand", but the power comes from the
> feedback mechanisms themselves.

>From: "Michael Haupt" <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: "The general-purpose Squeak developers
>list"<[hidden email]>
>Subject: Re: Common Smalltalk VM Summit
>Date: Fri, 6 Oct 2006 19:32:35 +0200
>
>I hope I'm not adding to your confusion. :-)
>
>Best,
>
>Michael
>

>From: "David Griswold" <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: "The general-purpose Squeak developers
>list"<[hidden email]>
>Subject: RE: Common Smalltalk VM Summit
>Date: Fri, 6 Oct 2006 11:18:27 -0700
>
>A lot of this confusion isn't your fault, it's the fault of the unfortunate
>choice of term "type-feedback," which is historical.  It is really "class"
>or "implementation type" feedback, and it is a mechanism *inside* the
>Strongtalk VM that dynamically tracks what instance classes occur at each
>send site, to learn how to inline and optimize those sends.
>
>The Strongtalk "type system" is a *completely* unrelated subsystem, that
>runs outside the VM in Smalltalk.  Strongtalk types are not implementation
>or class types, but pure interface types, that have nothing to do with
>classes, so they are not useful for optimization.  They are used purely to
>check the code and make it more structured and understandable, and are
>based
>on static analysis, not dynamic analysis.
>
>So Strongtalk has two, unrelated features: a dynamic type(class)-feedback
>VM, and a Smalltalk static type(interface)-checker.
>-Dave
>