GDScript: Optimize operators by assuming the types #79990
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This assumes that operators are called usually with the same type of operands as the first time. So it stores the types of the first run and if matched it uses an optimized path by calling the validated operator function directly. Otherwise it uses the regular untyped evaluator. With this change, if operators do use the same type they run quite faster. OTOH, if the types mismatch it takes longer to run than they would with the previous code.
adamscott
approved these changes
Jul 28, 2023
There was a problem hiding this comment.
This seems right, even if I'm not used to the codegen part of the codebase.
This compounds, right? If you're doing things correctly, in a _process() loop (or in any loop), the optimization would be run each iteration, if I understand correctly.
And this makes me think that we should have a "trivia" or a "advanced notes" in the docs for GDScript for tidbits like that.
|
I think the rationale here is that in the vast majority of cases you are expected to use the same types always, so it should be a net win in general. |
|
The assumed type optimizations can be implemented in a lot of places in the VM given now Godot has pointers to functions for almost everything. |
YuriSizov
approved these changes
Aug 1, 2023
|
Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This assumes that operators are called usually with the same type of operands as the first time. So it stores the types of the first run and if matched it uses an optimized path by calling the validated operator function directly. Otherwise it uses the regular untyped evaluator.
With this change, if operators do use the same type they run quite faster. OTOH, if the types mismatch it takes longer to run than they would with the previous code.
Note: this change may be a bit controversial as it makes operators slower when they fall in the non-optimized path (i.e. when the current operand types are different than the ones during the first run). The first time it ever runs is much slower, but since they are expected to run multiple times, this cost is amortized over time, as long as the optimized path is hit often.
I measured about 20% to 30% decrease in the execution time, when it falls into the optimized path. There's about 15% to 25% increase when it falls into the non-optimal path. All compared to the previous implementation of the operator opcode.
This doesn't affect validated operators (i.e. when types are known at compile time). The validated version is still faster.