[squeak-dev] FullBlockClosures and ignoreOuterContext?

Eliot Miranda eliot.miranda at gmail.com
Sat Jan 2 17:34:03 UTC 2021


Hi Stefan,

> On Jan 2, 2021, at 6:18 AM, Stefan Marr via Squeak-dev <squeak-dev at lists.squeakfoundation.org> wrote:
> 
> Hi Fabio:
> 
>> On 2 Jan 2021, at 12:49, Fabio Niephaus <lists at fniephaus.com> wrote:
>> - In terms of performance, Sista makes almost no difference in TruffleSqueak.
> 
> I would expect a benefit in terms of cold-code/interpreter performance.
> Do you see any benefits here?

There are two things here, one going on, the other not going on.

Sista, the adaptive optimizer architecture, includes Scorch, the image-level speculative compiler. Scorch is not (yet) in use. Clément is at Google and I don’t have the cycles to work on it.  But Sista and Scorch require the SistaV1 bytecode set, which is a set capable of expressing normal Smalltalk and optimizations, and a set that lifts limits on maximum method size, supports separate method objects for closures, etc.

In Squeak we’ve moved to using the SistaV1 bytecode set but are of the order of six months to a year of engineering effort away from putting Sista the architecture into production. Doing so depends on a more productive development architecture, using the vm simulator and mirrors to allow Scorch to live alongside the simulator and optimize the image being simulated, not the current image, hence insulating the current image from bugs in Scorch.

This could be a really interesting PhD and I’d love to collaborate.  But if the community simply waits for me to do the work it’ll be years before its complete.  I have a very full plate.

Of course nothing will happen from Potsdam; they get their funding from Oracle, from Mario as I understand of, and right now that prevents competent people such as Fabio from working on Scorch itself and has them merely spectating, waiting to take advantage of something no one is putting resource into.  It’s a frustrating and tragic situation.  [I say tragic because my understanding of Shakespeare’s tragedies is that they are all driven by character]

Some creativity on behalf of us all seems necessary if this work isn’t going to go to waste.  I’m extremely frustrated with this situation.  If people can’t find a way of collaborating with me and only find ways of finding what are effectively disruptive efforts then the project will eventually wither and die.

I’m working for 3dIcc.com and we’re teetering on the brink.  If we can get customers we can survive and I can become self-funding and may, in the remaining eight years to my seventieth birthday, have time to complete Sista; I certainly want to.  But if the community could somehow find one or two people of Clément’s abilities to join me directly in the work, rather than simply spectating a body in a coma, then there is a good chance that Sista could be in production within a year or two.

Yes I’m angry and frustrated. You would be too.

> 
>> which could greatly improve warmup.
> 
> Less run-time work for optimizers is one possible benefit, but I would expect the interpreter itself to also shows some performance difference.
> For instance, I’d assume there’s less needed for run-time specialization in the Truffle interpreter, and the Truffle interpreter code being less polymorphic.
> Is that the case/measurable?
> 
> Best regards
> Stefan
> 
> 
> -- 
> Stefan Marr
> School of Computing, University of Kent
> https://stefan-marr.de/research/

HNY!!

Eliot
_,,,^..^,,,_ (phone)


More information about the Squeak-dev mailing list