5 ms·

That bouncing atoms video just blew my mind. It took whole minutes, but it got so incredibly fast... Only to grind to a halt as soon as the workload changed jus

That bouncing atoms video just blew my mind. It took whole minutes, but it got so incredibly fast... Only to grind to a halt as soon as the workload changed just a little, haha. I'd imagine you have a ton of bigger priorities, but being so hackable I wonder if there are easy tools within Graal/Truffle to hit that peak performance sooner and be stabler. I'd never expected it to stall so aggressively, probably worse than full GC. Still, blown away.

logicchains 6y ago
> Only to grind to a halt as soon as the workload changed just a little, haha. What really amazed me is the second time the mouse moved over the toolbar, towards the end of the video, it lagged less and was able to recover to the 200+fps much faster than the first time.
- fniephaus 6y ago
  Correct, this indicates that recompilation occurred. The first time Graal compiled some of the UI machinery, which is all written in Smalltalk, no input events were triggered in the IDE. Consequently, the partial evaluator removed those code paths from compiled code. When we move the mouse over the window or start to click on UI elements, we cause recompilation, now with event handling compiled in. That's why these performance cliffs go away over time.
  - tinco 6y ago
    Would it help to for example run a full test suite on your project, and use the compilation results of that as a sort of base? I remember a long time ago C# had a feature like this.
    - fniephaus 6y ago
      It would only if the test suite represents a realistic workload of your program. BTW: GraalVM EE has support for profile-guided optimizations: https://medium.com/graalvm/improving-performance-of-graalvm-native-images-with-profile-guided-optimizations-9c431a834edb https://medium.com/graalvm/improving-performance-of-graalvm-...
fniephaus 6y ago
The Graal compiler is known to be slow in terms of warmup. At the same time, it provides great peak-performance. However, and as you can see in the video, partial evaluation will trigger recompilation if the program is not "stable". And when you're interacting with an IDE, it will take quite some time for the IDE to become stable. Even worse, some things like debugging sessions will never be stable. Of course, it doesn't make much sense to run your IDE at +60FPS. Squeak usually throttles the frame rate, and then the performance cliffs are harder to notice. Nonetheless, the GraalVM team is very much aware of these problems and is actively working on them. We are only the first to visualize this in the form of an IDE. A couple of GraalVM releases ago, they introduced libgraal [1], which improved compilation times significantly. One idea to make this even better is to persist compiled code from the JIT, so that it can be reused the next time you run the program/IDE. Morphic, Squeak's UI framework, is unlikely to change and could be warmed up in advance. [1] https://medium.com/graalvm/libgraal-graalvm-compiler-as-a-precompiled-graalvm-native-image-26e354bee5c https://medium.com/graalvm/libgraal-graalvm-compiler-as-a-pr...
- grashalm 6y ago
  Truffle team lead here. Yes we are working full steam on improving warmup and delays caused by going back to the interpreter in unexpected cases. Expect bigger improvements in this area soon. That being said, we cannot do it all on the Truffle side without help of the language implementation. Truffle languages speculate on certain aspects of the program data. If they do so, then we need to deoptimize and invalidate the optimized code when this speculation is violated. So the stability of the language implementation really is an important factor. Questions like "do we need to speculate on this value being constant or does give us enough benefit to justify the deoptimization overhead?" need to be answered by the language implementation and not the Truffle framework. Afaik this was not a priority for TruffleSqueak so far, but it might be in the future. So there are potentialy future improvements also on the TruffleSqueak side.
  - kjeetgill 6y ago
    I had no idea speculation was surfaced up through Truffle. That's so cool.

logicchains 6y ago

> Only to grind to a halt as soon as the workload changed just a little, haha. What really amazed me is the second time the mouse moved over the toolbar, towards the end of the video, it lagged less and was able to recover to the 200+fps much faster than the first time.

fniephaus 6y ago
Correct, this indicates that recompilation occurred. The first time Graal compiled some of the UI machinery, which is all written in Smalltalk, no input events were triggered in the IDE. Consequently, the partial evaluator removed those code paths from compiled code. When we move the mouse over the window or start to click on UI elements, we cause recompilation, now with event handling compiled in. That's why these performance cliffs go away over time.
- tinco 6y ago
  Would it help to for example run a full test suite on your project, and use the compilation results of that as a sort of base? I remember a long time ago C# had a feature like this.
  - fniephaus 6y ago
    It would only if the test suite represents a realistic workload of your program. BTW: GraalVM EE has support for profile-guided optimizations: https://medium.com/graalvm/improving-performance-of-graalvm-native-images-with-profile-guided-optimizations-9c431a834edb https://medium.com/graalvm/improving-performance-of-graalvm-...

fniephaus 6y ago

The Graal compiler is known to be slow in terms of warmup. At the same time, it provides great peak-performance. However, and as you can see in the video, partial evaluation will trigger recompilation if the program is not "stable". And when you're interacting with an IDE, it will take quite some time for the IDE to become stable. Even worse, some things like debugging sessions will never be stable. Of course, it doesn't make much sense to run your IDE at +60FPS. Squeak usually throttles the frame rate, and then the performance cliffs are harder to notice. Nonetheless, the GraalVM team is very much aware of these problems and is actively working on them. We are only the first to visualize this in the form of an IDE. A couple of GraalVM releases ago, they introduced libgraal [1], which improved compilation times significantly. One idea to make this even better is to persist compiled code from the JIT, so that it can be reused the next time you run the program/IDE. Morphic, Squeak's UI framework, is unlikely to change and could be warmed up in advance. [1] https://medium.com/graalvm/libgraal-graalvm-compiler-as-a-precompiled-graalvm-native-image-26e354bee5c https://medium.com/graalvm/libgraal-graalvm-compiler-as-a-pr...

grashalm 6y ago
Truffle team lead here. Yes we are working full steam on improving warmup and delays caused by going back to the interpreter in unexpected cases. Expect bigger improvements in this area soon. That being said, we cannot do it all on the Truffle side without help of the language implementation. Truffle languages speculate on certain aspects of the program data. If they do so, then we need to deoptimize and invalidate the optimized code when this speculation is violated. So the stability of the language implementation really is an important factor. Questions like "do we need to speculate on this value being constant or does give us enough benefit to justify the deoptimization overhead?" need to be answered by the language implementation and not the Truffle framework. Afaik this was not a priority for TruffleSqueak so far, but it might be in the future. So there are potentialy future improvements also on the TruffleSqueak side.
- kjeetgill 6y ago
  I had no idea speculation was surfaced up through Truffle. That's so cool.