Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introducing @BuiltinMethod.inlineable and InlineableNode #6442

Merged
merged 16 commits into from
Apr 28, 2023

Conversation

JaroslavTulach
Copy link
Member

@JaroslavTulach JaroslavTulach commented Apr 26, 2023

Pull Request Description

Fixes #6416 by introducing InlineableNode. It runs fast even on GraalVM CE, fixes (forever broken) Debug.eval with <| and removes discouraged subclassing of DirectCallNode. Introduces @BuiltinMethod.inlineable - something that was requested by #6293. Just in this PR the attribute is optional - its implicit value continues to be derived from VirtualFrame presence/absence in the builtin method argument list. A lot of methods had to be modified to pass the VirtualFrame parameter along to propagate it where needed.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

  • All code follows the
    Java,
  • All code has been tested:
    • Unit tests have been written where possible.
    • Benchmarks are good on GraalVM CE

@JaroslavTulach JaroslavTulach added CI: No changelog needed Do not require a changelog entry for this PR. --low-performance labels Apr 26, 2023
@JaroslavTulach JaroslavTulach added this to the Design Partners milestone Apr 26, 2023
@JaroslavTulach JaroslavTulach requested a review from 4e6 as a code owner April 26, 2023 16:48
@JaroslavTulach JaroslavTulach self-assigned this Apr 26, 2023
@JaroslavTulach JaroslavTulach requested a review from hubertp as a code owner April 26, 2023 16:48
* @param <E> extra data to keep in the node
* @param <N> node to delegate to from {@link #call(java.lang.Object...)} method
*/
protected abstract static class InlinedCallNode<E, N extends Node> extends DirectCallNode {
Copy link
Member Author

@JaroslavTulach JaroslavTulach Apr 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've been warned (in addition to the javadoc warning), that subclassing DirectCallNode creates unnecessary polymorphism when calling DirectCallNode.call. Such a polymorphism isn't a problem for "PE mode" (the Node being invoke is always a compilation constant, so it is clear what call is going to be invoked), but before the JVM gets there, it slows things down (Node isn't compilation constant for the regular JVM).

Replacing with a parallel InlineableNode concept.

|
|main =
| x = "Hello World!"
| Debug.eval <| $rawTQ
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The combination of Debug.eval and <| was always broken. The <| builtin was providing its own VirtualFrame to the Debug code. Now the <| builtin specifies needsFrame = false and gets the caller's frame instance. As such it provides the right frame to the Debug subsystem.

@JaroslavTulach JaroslavTulach changed the title Introducing @BuiltinMethod.needsFrame that can overide the default Introducing @BuiltinMethod.needsFrame and InlineableNode Apr 27, 2023
@JaroslavTulach
Copy link
Member Author

JaroslavTulach commented Apr 27, 2023

Running benchmarks to check the effect of the changes. Good, the ifBench6In is now sped up even on GraalVM CE:

IfVsCaseBenchmarks.ifBench6In   21.32783      1.29492    -93.92852%

Let's perform one more benchmark run with the most recent state to verify the results. Alas, there seems to be a slowdown in

ArrayProxyBenchmarks.sumOverVectorBackedByDelegatingProxy    0.36719      0.97045         +164.28833%

I am going to ignore this 164% decrease result. I am running benchmarks since the morning, both on develop as well as on my branch and the results oscillate from 220ms/op to 400ms/op on both branches. Just right now I got:

Result "org.enso.interpreter.bench.benchmarks.semantic.ArrayProxyBenchmarks.sumOverVectorBackedByDelegatingProxy":
  0.224 ±(99.9%) 0.014 ms/op [Average]
  (min, avg, max) = (0.218, 0.224, 0.228), stdev = 0.004
  CI (99.9%): [0.210, 0.238] (assumes normal distribution)

which is close to the best result I've ever seen. This result was achieved on 162048a - that's a signal this branch is doing fine, I think.

build.sbt Outdated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When running sbt:interpreter-dsl-test/test on a clean build, I get multiple warnings of type:

[warn] Could not determine source for class org.enso.interpreter.dsl.test.InliningBuiltinsInMethodGen

Moreover, In IntelliJ, I seem to be unable to locate generated sources, e.g., InliningBuiltinsInMethodGen, which results in poor inspection of InliningBuiltinsTest.java. @hubertp shouldn't there be an explicit setting for sourceManaged directory for interpreter-dsl-test project? I guess we should get rid of all the warnings even in tests.

Copy link
Member

@Akirathan Akirathan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some minor nitpicks. I would really like to see the needsFrame renamed to forceInlining - see my comments in the code. I find the needsFrame name perplexing. Apart from that seems very impressive, I can't wait to see the benchmark results.

Copy link
Collaborator

@hubertp hubertp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor nits

@JaroslavTulach JaroslavTulach added CI: Ready to merge This PR is eligible for automatic merge CI: Clean build required CI runners will be cleaned before and after this PR is built. labels Apr 28, 2023
@JaroslavTulach JaroslavTulach removed the CI: Clean build required CI runners will be cleaned before and after this PR is built. label Apr 28, 2023
@mergify mergify bot merged commit efe904c into develop Apr 28, 2023
@mergify mergify bot deleted the wip/jtulach/FastOnGraalVMCE_6416 branch April 28, 2023 15:32
@JaroslavTulach JaroslavTulach changed the title Introducing @BuiltinMethod.needsFrame and InlineableNode Introducing @BuiltinMethod.inlineable and InlineableNode Apr 28, 2023
Procrat added a commit that referenced this pull request May 3, 2023
* develop: (34 commits)
  Continued Execution Context work and some little fixes (#6506)
  IDE's logging to a file (#6478)
  Fix application config (#6513)
  Cloud/desktop mode switcher (#6448)
  Fix doubled named arguments bug (#6422)
  Reimplement `enso_project` as a proper builtin (#6352)
  Fix layer ordering between dropdown and breadcrumbs backgrounds.  (#6483)
  Multiflavor layers (#6477)
  DataflowAnalysis preserves dependencies order (#6493)
  Implement `create_database_table` for Database Table (#6467)
  Limit Dead Letter logging (#6482)
  More reliable shutdown of the EnsoContext to save resources (#6468)
  Make execution mode `live` default for CLI (#6496)
  Finishing Vector Editor (#6470)
  Proper handling of multiple list views. (#6461)
  Fix disappearing cached shapes (#6458)
  Add Execution Context control to Text.write (#6459)
  Change defaults for `Connection.tables` and ensure that `Connection.query` recognizes all available tables (#6443)
  Introducing @BuiltinMethod.needsFrame and InlineableNode (#6442)
  Hide profile button behind a feature flag (#6430)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
--low-performance -compiler CI: No changelog needed Do not require a changelog entry for this PR. CI: Ready to merge This PR is eligible for automatic merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Improve inlining of <| on GraalVM CE
3 participants