bera.clement at gmail.com
Sat Mar 12 20:56:03 UTC 2016
2016-03-12 21:19 GMT+01:00 Florin Mateoc <florin.mateoc at gmail.com>:
> 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:
> 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.
That would be great.
> 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.
I do type inference but I don't do it based on class hierarchy nor using
For each method or block, the optimizer looks in the inline caches in the
machine code to find out the types met for the receiver of each send. This
way, the optimizer speculates on the types of specific objects, performs
inlining and insert guards that trigger dynamic deoptimization of the code
if the type assumptions are no longer correct. Then, specific variables are
typed based on the guards. I am also adding with Eliot some constraints on
literals so they can't be become, this way the optimizer know the literal
types, and become operations requires dynamic deoptimization of specific
methods using the become object as a literal.
For #isKindOf: and #is..., depending on what is actually inlined, the
optimizer can do a good job or not. If #isKindOf: is effectively inlined to
a type check, then I guess the type could be effectively inferred but its
not currently the case as we have not added yet a feature to forbid literal
variable edition, hence the optimizer can't know for sure that if the
literal variable holding the class won't be mutated later.
Currently the main performance boost lies with method/closure inlining,
array bounds check elimination and constant-folding/global value numbering.
Maybe later I will need more accurate type and will consider implementing
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev