[russellallen]

Its great to see this here.

I vaguely recall some mention in one of the docs I read a while back that you were having difficulties with the JIT causing noticable pauses/latency in interactive environments like Morphic, comparison to the OpenSmalltalkVM.

Am I recalling correctly, and if so is it still the case?

And more generally, in comparison to the OpenSmalltalkVM, what are the TruffleSqueak downsides? The upsides seem nicely obvious!

[fniephaus]

Thanks!

> I vaguely recall some mention in one of the docs I read a while back that you were having difficulties with the JIT causing noticable pauses/latency in interactive environments like Morphic, comparison to the OpenSmalltalkVM.

Right, have a look at the sub-discussion at https://news.ycombinator.com/item?id=24182587.

> Am I recalling correctly, and if so is it still the case?

GraalVM and TruffleSqueak have evolved quite a bit, but it is still the case. With libgraal, TruffleSqueak warms up much faster, and we were able to further improved the performance of TruffleSqueak. If you'd like to give it a try, it should be fairly easy to get started: https://github.com/hpi-swa/trufflesqueak#getting-started

> And more generally, in comparison to the OpenSmalltalkVM, what are the TruffleSqueak downsides? The upsides seem nicely obvious!

TruffleSqueak passes quite a lot of Squeak's SUnit tests (see [2]), but is of course not 100% compatible yet. Proper support for some plugins (e.g. FFI, OSProcess, ...) is still missing.

Apart from that, I'd say that TruffleSqueak has to live with the design decisions made in Truffle, but we can build on and reuse all of GraalVM components (e.g. JIT, GC, ...). The OpenSmalltalkVM, on the other hand, is more flexible, but you have to implemented everything from scratch.

[2] https://github.com/hpi-swa/trufflesqueak/runs/990481811?chec...

[russellallen]

Cool. That video of the bouncing atoms demo is fascinating.

It seems like a revisiting of the experience of the Self team between the second and third generation of Self VMs[1], though the underlying hardware might be just a little faster :) Do you think this tradeoff of peak performance vs interactivity is inherent in Tuffle's approach? Or can Truffle realistically aim for the best of both worlds?

One interesting aspect of the Self VM is that it can save the JIT generated native machine code together with the Self code in the image/snapshot, so that you can load a pre-warmed set of objects. Is that possible within the Truffle framework?

[1] https://bibliography.selflanguage.org/_static/third-generati...

[fniephaus]

> It seems like a revisiting of the experience of the Self team between the second and third generation of Self VMs, though the underlying hardware might be just a little faster :) Do you think this tradeoff of peak performance vs interactivity is inherent in Truffle's approach? Or can Truffle realistically aim for the best of both worlds?

> One interesting aspect of the Self VM is that it can save the JIT generated native machine code together with the Self code in the image/snapshot, so that you can load a pre-warmed set of objects. Is that possible within the Truffle framework?

I completely agree. Mario Wolczko, who worked on the Self VM at that time, is part of the extended GraalVM team. So the knowledge and experience is there, it only has to be implemented. The GraalVM team is thinking about ways to support snapshotting and a couple of other things. Their profile-guided optimizations [1] is probably the closest to that and definitely a way into the right direction. So I'd say it is possible to make performance of GraalVM languages much more predictable, maybe to the extent that it doesn't matter anymore for interactivity.

[1] https://medium.com/graalvm/improving-performance-of-graalvm-...

[Rochus]

> and we were able to further improved the performance of TruffleSqueak

Is there an overview somewhere which allows comparison with fig. 4 of your ACM 2019 publication? Anyway in that publication SOMns using the same technology - as far as I understand - showed a completely different performance pattern; does this still apply, and what is/was the reason for this?

[fniephaus]

> Is there an overview somewhere which allows comparison with fig. 4 of your ACM 2019 publication?

We have set up a benchmarking infrastructure for performance tracking, but it is unfortunately not public (yet). Also, we have switched from GraalVM EE/JDK8 to GraalVM CE/JDK11 a couple of months ago, which makes it hard to compare recent with older results. But what I can say it that performance on GraalVM CE/JDK11 is currently better than on GraalVM EE/JDK8 a year ago. I expect it to be faster on EE as well, but I'd need to measure by how much.

> Anyway in that publication SOMns using the same technology - as far as I understand - showed a completely different performance pattern; does this still apply, and what is/was the reason for this?

Correct. First, SOMns does not support a real Smalltalk system and does not support some crucial mechanisms (e.g. changing the class of an object). So TruffleSqueak must check the class of an object in quite some cases, which is a slight, unavoidable overhead. More importantly, SOMns has some primitives that Squeak does not, for example for comparing strings. That's for example another reason why SOMns is so much faster in the JSON benchmark. For your curiosity, here's a screenshot of the benchmark results for a current TruffleSqueak and SOMns (note that they ran on different versions of GraalVM, I think you can somewhat compare the TruffleSqueak numbers to "GraalSqueak-CE" in fig. 4 of the paper):

https://user-images.githubusercontent.com/2368856/90402527-d...

[Rochus]

Interesting, thanks. Still surprising it is a factor of two.