On Tue, 22 Dec 2020 at 9:35 am, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

> Hi Fabio,
>
> > On Dec 20, 2020, at 1:27 PM, Fabio Niephaus <lists at fniephaus.com> wrote:
> >
> > Hi Eliot,
> >
> >> On Tue, Dec 15, 2020 at 3:06 AM Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
> >>
> >> Hi Fabio,
> >>
> >>> On Mon, Dec 14, 2020 at 1:33 PM Fabio Niephaus <lists at fniephaus.com>
> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> While digging through the implementation of FullBlockClosure with
> >>> Hernan, we were wondering about full closures that ignore their
> >>> outerContext. We noticed that the following method has two senders:
> >>>
> EncoderForSistaV1>>#genPushFullClosure:numCopied:receiverOnStack:ignoreOuterContext:
> >>>
> >>> One of them seems to be the only one in use, and it's passing in false
> >>> as defaults for both receiverOnstack and ignoreOuterContext. The other
> >>> sender
> (BytecodeEncoder>>#sizePushFullClosure:numCopied:receiverOnStack:ignoreOuterContext:),
> >>> in turn, doesn't seem to have any further senders.
> >>>
> >>> Unless we missed something, it looks like the outerContext will never
> >>> be ignored at the moment. Similarly, the receiver is never on the
> >>> stack. Is this something only Scorch can do or is this just "not yet
> >>> implemented"?
> >>>
> >>> When can the outerContext be ignored?
> >>
> >>
> >> When the Sista optimizer determines that it isn't needed. i.e. this
> option is nover used in vanilla code but exists for an optimizing compiler
> to avoid the overhead in cases where it wants to avoid inlining but knows
> there is no real suspension point during some evaluation.  Now, whether
> we'll ever use this facility I can't say, but it was certainly in Clément's
> mind to do so at some point.
> >>>
> >
> > Ok, thanks for the info!
> >
> >>> When does it make sense to pop the receiver from the stack?
> >>
> >>
> >> The point isn't really to pop the receiver from the stack.  The point
> is to be able to take the closures receiver form the stack rather than it
> being implicitly the receiver of the current method.  If closure creation
> gets inlined by the optimizer then there will be potentially a mismatch
> between the current method's receiver and an inlined closure's receiver,
> which necessitates having the facility to specify a distinct receiver.
> >>
> >
> > Makes sense, thanks!
> >
> >>
> >>>
> >>> And where can we find the latest version
> >>> of Scorch. Is it still the one at [1]?
> >>
> >>
> >> http://smalltalkhub.com/mc/ClementBera/Scorch/main
> >
> > Oh, isn't smalltalkhub read-only these days?
>
> If it is then things need to move once time is found to work on the code
> again.
>
> >
> >>
> >> If you're interested in looking at Scorch I'm very interested in
> collaborating.  And there ius one significant modification to perform first
> which will make development much easier, and that is to restructure the
> interface between the optimizer and the image via mirrors, allowing the
> optimizer to be mated with an image being simulated, rather than having to
> be a full peer of the image it is optimizing.
> >
> > Since we turned on full closures and Sista in Squeak, I could no
> > longer use trunk images on top of TruffleSqueak. I finally decided to
> > bite the bullet and worked on support for both in the last two weeks.
> > It's not that I don't want to collaborate and help evolve Scorch (it's
> > a fascinating project!). It's just that I don't have the time to work
> > on any significant contributions in that direction. Nonetheless, I'd
> > love to see someone working on it again.
>
> Ah ok, makes sense.  Now you’ve implemented the Sista set I’m curious how
> you evaluate the design.


I've actually worked on another implementation for SqueakJS in the meantime
(see [1]) ... here are some quick thoughts:

- I like that bytecodes are ordered by the number of bytes they consume (1,
2, 3). This makes implementations a bit easier to read (e.g. looking up the
number of bytes per bytecode is very simple).

- I noticed that some parts are still unfinished and I couldn't always
guess what the plan was. Bytecodes 0x52 and 0x5E, for example, take the
extension bytes under consideration. Right now, however, they only do
something if the corresponding extension is 0. That's a bit odd, but I'm
guessing the plan was to add more controls...not sure which though.
Extension bytes in general are a nice concept.

- FullBlockClosures are very much in line with how language implementation
frameworks (Truffle, RPython) imagine closures. It was therefore quite easy
to support them in TruffleSqueak. However, and as I found out in this
thread, the implementation is also unfinished. Right now, the outer context
is never ignored, so the overhead is comparable to old closures. I thought
the Squeak compiler would ignore the outer context if non-local returns are
not present. Maybe that's something we should try out next?

- In terms of performance, Sista makes almost no difference in
TruffleSqueak. For tinyBenchmarks, the compiler output is even identical.
Therefore, it seems the Graal compiler can optimise Sista just as good as
the old bytecode set, which is an interesting result. I expect to observe
the same when running with Scorch. The optimisations done by Scorch are
probably quite similar to what Graal does, only on a much higher level and
then Graal would only have less to do. The main difference though is that
Scorch optimisations are persisted within the image, which could greatly
improve warmup.


Fabio

[1]
https://github.com/codefrau/SqueakJS/blob/deaf0a5ca0b02d3dc9608fee6b7d9d544a4962da/vm.interpreter.js#L351



>
> Eliot
> _,,,^..^,,,_ (phone)
>
> >
> > Fabio
> >
> >>>
> >>> Cheers,
> >>> Fabio
> >>>
> >>> [1] https://github.com/clementbera/Scorch
> >>
> >>
> >> _,,,^..^,,,_
> >> best, Eliot
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210102/944e229d/attachment.html>