Reevaluate jump threading in GDScript VM #11418
Labels
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
{{ message }}
Describe the project you are working on
godot gdscript module
Describe the problem or limitation you are having in your project
I'm trying to add immediate number to gdscript vm instruction, having two implementation (jump threading/loop) significantly increase the workload and maintainability burden.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
According to https://inria.hal.science/hal-01100647/document, as our hardware evolve, jump threading is playing less important role in reducing branch prediction misses.
I test the two version with godot-benchmark, the results are as below:
Template Release
Editor
Overall jump threading version is 2%~3% faster.
Breaking down with Intel VTune Profiler shows that the speedup mainly comes from reduced inst count instead of branch misses.
The retired instruction diff is at the same percent as the execution time diff, and the IPC is the same, meaning jump threading is faster mainly because it execute less instructions.
As a conclusion, I think 2~3% speed is totally trade-offable with maintainability. Without jump threading we can split the huge
GDScriptFunction::call, full of macro magic, into small, standard, readable part. Also you don't need to check compitability for two version when you do any change to the vm, make the enhancement a lot easier to be done.Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
Remove jump threading version of VM, split
GDScriptFunction::call. Not a very hard thing if the proposal is widely accepted.If this enhancement will not be used often, can it be worked around with a few lines of script?
No.
Is there a reason why this should be core and not an add-on in the asset library?
part of godot.
The text was updated successfully, but these errors were encountered: