[Vm-dev] InterpreterSimulator

[Florin Mateoc]

On 3/12/2016 2:44 PM, Clément Bera wrote:
>  ransformations are AST based? Is there any documentation?
>
> Hello Florin,
>
> /How is Sista being developed (is it developed in the open (in trunk))? Where is the source code?/
>
> The sista backend (JIT extension, primitive support, etc) is in the trunk in slang. The image-level source code is on
> a separate repository on smalltalkhub. It will be merged at some point when sista will be production ready. Depending
> on configurations, you can load the image-level code for Squeak or Pharo with different tool extensions. In Pharo
> tools are slightly better as I can use Roassal to display control flow graphes, but on Squeak the IDE is way more
> stable on partially broken images like when you are actually running on top of the sista VM and incorrect optimized
> method are installed, so you can use what you need depending on what you do. Typically, I use Pharo to implement/debug
> optimization pass, then use quick to debug the running system and implement VM-image interface.
>
> /How does one contribute? /
>
> Not obvious to answer shortly... Let's say firstly that we would welcome a new contributor.
>
> To contribute to the backend you need to commit on the trunk. There are different things you could do there already.
> Are you familiar with the JIT implementation ?
>
> To contribute on the image-level code I guess you can commit on the Smalltalkhub repo, but ...
>
> I am currently reworking the dynamic deoptimization hence the bleeding edge is not stable at all any more. In addition
> I did lots of debugging and I need to check again things like dependencies to other packages and remove debugging
> code. Lastly, I hacked a lot range optimzations and the optimization process is generating more efficient code but is
> now unclear and long to run. I think I need to fix that part to make it easier to understand as I did for inlining.
>
> A few months ago, when it was fairly stable, I could run the game benchs with this kind of results (time to run of
> sista+spur compared regular spur, those were the worst cases, sometimes it got 20% better):
> nbody:  -35% 
> threadring: -40%
> binarytrees: -20%
> nbody: -35% 
> fibonacci: -35%
> integer benchmark: -10%
>
> To contribute, we can chat on skype to show you what we have and what you can do.
>
> I am going to work with Eliot on April on it and we're going to introduce some big changes, especially on closure
> support. 
>
> Due to the current status (bleeding edge unstable + the big changes we'll do in April), it is currently quite
> difficult to contribute to the image-level code. So, either you wait until mid April, and contribute to the back-end
> until then, or as you look motivated, we could talk and see if you can do something now, though it won't be obvious.
> If I'd know you'd want to contribute last month I would have been more careful. 
>
> I don't have that much time right now but we could talk an hour sometime.
>
> /How do you guys communicate (is there a separate mailing list)?/
>
> Well, it's mainly Eliot and I working on it so we skype and send each other mails. Sometimes we include Ryan too as he
> is interested. We could create a mailing list I guess, not sure if worth it.
>
> /The SSA representation and the transformations are AST based?/
> /
> /
> Not really, it is also a high-level representation, somewhere in between AST and bytecode levels. The optimizer
> decompiles to its own IR, then do the passes and generates back the optimized method. The IR is not a tree as the AST
> or in gcc, but a control flow graph, similar to V8 Crankshaft's IR hydrogen, also similar but on a higher level than
> LLVM IR. It's not a sea of nodes as Graal and co. The nodes are a bit different from the AST as there are no temporary
> variables in SSA representations. A few other nodes exist like unchecked operations, phi nodes or guards.
>
> /Is there any documentation?/
>
> Well I tried to write documentation at some point, but the code based changed a lot a few times, and it will change
> quite a lot again with the changes we will do with closures. As long as the first release does not happen, I don't
> think there will be a lot of documentation due to the high rate of changes.
>
> I believe I kept the code very well commented (though it depends on your standards). Each class should have a comment
> describing what her instances do and how, sometimes with references on the algorithm used.
>
> The paper we wrote at ESUG can help, I believe it's quite well written:
> http://esug.org/data/ESUG2014/IWST/Papers/iwst2014_A%20bytecode%20set%20for%20adaptive%20optimizations.pdf
>
> Else I am writing another paper on the overall architecture right now, I will attempt to submit at oopsla even if it
> will be done quickly, I guess I could share with you at this point if you promise *not* to do something stupid with
> unreleased papers, like showing it to the wrong people.
>
> Lastly there are the Aosta (pre-sista project) sketches from Eliot and al. I put it in attachment.
>
> My turn to ask question :-) 
> Are you engineer, student, something else ? 
> Would you contribute to sista a few hours a week, a few hours a month, ... ? 
> Note that aside from new features / stabilization / optimizations passes, making the code easier to read, writing
> documentation or having clever remarks are valid contributions to us.
> I can give you a few tasks to get you started if you want.
>

Hi Clément,

Thank you for taking the time to reply.

Unfortunately my interest and experience mostly relate to image-level - I am an Electrical Engineer and I climbed my way
up from assembly to C, to C++, and up to Smalltalk (and then down to Java), but that was a long time ago. More recently
I have worked a lot on type inferencing for Smalltalk, as well as on source-to-source translation (based on ASTs
enhanced with type information), both Smalltalk to Smalltalk and Smalltalk to Java.

I could contribute to sista a few hours a week.

And now on to clever remarks :)
Are you doing type inferencing and have you considered using SSI instead of SSA? For inheritance-based languages with
deep hierarchies like Smalltalk uses, type-discrimination tests (and I don't just mean #isKindOf: or even #is... methods
in general) are both common and important to take advantage of for accurate type inferencing.

Florin


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160312/ce30f699/attachment.htm