8000 Spread transform/traverse/mapOver into virtual methods of Tree/Type by retronym · Pull Request #6060 · scala/scala · GitHub
[go: up one dir, main page]

Skip to content

Spread transform/traverse/mapOver into virtual methods of Tree/Type #6060

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

Merged
merged 7 commits into from
Dec 4, 2017

Conversation

retronym
Copy link
Member
@retronym retronym commented Sep 6, 2017

Analysis of JIT logs shows that a handful of very hot pattern matches in tree and type traversal run through ~10 deoptimizations before finding a steady state. Even once JITted, they show up in profiles as consuming a few percent of time, even though they are mostly just doing dispatching.

In this PR, I have changed them to virtual calls. Analysis of the JIT logs shows better stability for these methods, and the benchmarks suggest that the compiler has better peak performance.

@scala-jenkins scala-jenkins added this to the 2.13.0-M3 milestone Sep 6, 2017
@retronym
Copy link
Member Author
retronym commented Sep 6, 2017

Benchmarks scheduled to appear soon. I measured approx 4% speedup for the scalap benchmark locally.

@retronym
Copy link
Member Author
retronym commented Sep 6, 2017

Reviving #5906, although I'd forgotten about the test failures that need investigation ☹️

@retronym retronym added performance the need for speed. usually compiler performance, sometimes runtime performance. WIP labels Sep 6, 2017
@retronym retronym requested review from adriaanm and lrytz September 12, 2017 05:02
@retronym retronym force-pushed the faster/virtual-transform-minimal branch from 27e38bf to 0c04d64 Compare September 12, 2017 07:00
@retronym retronym removed the WIP label Sep 12, 2017
@retronym retronym changed the title Spread Tree transform/traverse/mapOver into virtual methods of Tree Spread transform/traverse/mapOver into virtual methods of Tree/Type Sep 12, 2017
Copy link
Member
@lrytz lrytz left a comment

Choose a reason for hiding this comment

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

Looks good! Can you provide some motivation in the message of the commit that reverts c2dc346?

@@ -1129,6 +1131,7 @@ trait Types
override def safeToString: String = "<error>"
override def narrow: Type = this
override def kind = "ErrorType"
override def mapOver(map: TypeMap): Type = this
Copy link
Member

Choose a reason for hiding this comment

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

There are many override def mapOver(map: TypeMap): Type = this added in this commit, and they are unnecessary in principle. I suggest to either make mapOver in Type abstract or throw, or remove all redundant overrides.

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmm, I can't remember the sequence of how I arrived at this. I do remember running into problems when Type became a SAM and the inliner (prior to #5895) was overzealous. Maybe I made this non-abstract as a workaround.

@sjrd
Copy link
Member
sjrd commented Sep 12, 2017

I see a lot of

-          super.transform(tree)
+          tree.transform(this)

in transforms. Are these mandatory with the new scheme? Will this likely break compiler plugins?

@lrytz
Copy link
Member
lrytz commented Sep 12, 2017

They continue to work, transformers still have a transform method that forwards to tree.transform.

@sjrd
Copy link
Member
sjrd commented Sep 12, 2017

Cool thanks :)

@retronym
Copy link
Member Author

Looks good! Can you provide some motivation in the message of the commit that reverts c2dc346?

I was aiming for cleaner stack traces in the transformers in order to make it a little easier to navigate through profiles. It didn't seem to make a difference to performance.

@retronym retronym force-pushed the faster/virtual-transform-minimal branch from 0290c18 to 9186c9d Compare September 13, 2017 08:46
@retronym
Copy link
Member Author
retronym commented Oct 6, 2017

Anything more needed by the reviewers?

This appears to perform better than the pattern match.
Possible factors at play:
  - vtable lookup is constant time vs pattern match requires a cascade
    of instanceof-s
  - megamorphic invokevirtual has more stable JIT profiles than a the
    match (parts of the match can appear to be dead code depending on
    what phase of the compiler JIT profiles the method.)
  - The new, small methods might in more inlinable into callers that
    are effectively mono morphic.
@adriaanm
Copy link
Contributor

There's a (trivial) conflict. I resolved and moved the revert to the last commit to make it easier to adapt the commit message. I didn't want to push -f to your branch. My branch is at https://github.com/adriaanm/scala/tree/faster/virtual-transform-minimal

@adriaanm
Copy link
Contributor

After that, LGTM

@retronym retronym force-pushed the faster/virtual-transform-minimal branch from 9186c9d to 962112a Compare December 1, 2017 04:40
@retronym
Copy link
Member Author
retronym commented Dec 1, 2017

Added a merge commit to resolve the conflict with #6089

@retronym retronym force-pushed the faster/virtual-transform-minimal branch from c847b52 to 02537a1 Compare December 4, 2017 00:32
@retronym
Copy link
Member Author
retronym commented Dec 4, 2017

/rebuild

@retronym
Copy link
Member Author
retronym commented Dec 4, 2017

Something was wonky with Jenkins in https://scala-ci.typesafe.com/job/scala-2.13.x-validate-main/567/console, the build flow claimed it was waiting for the integrate-ide job, but that has already finished.

@retronym retronym merged commit 05d409f into scala:2.13.x Dec 4, 2017
@retronym
Copy link
Member Author
retronym commented Dec 4, 2017

Merging on Adriaan's conditional LGTM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
performance the need for speed. usually compiler performance, sometimes runtime performance.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants
0