Optimise mrb_iv_get - #6294
Merged
Merged
Conversation
This allows the compiler to optimise the case in obj_iv_p into a range check. There does not seem to be any other very hot uses of this index and it grants a pretty big gain on optcarrot.
By adding a fast-path where we ignore boxed types we can gain a pretty substantial speedup of mrb_iv_get, making it about 25% faster during a standard optcarrot benchmark run. NOTE: It is just mrb_iv_get that is that much faster, the whole benchmark seems to be about 3-5% faster with word boxing.
Member
|
Thank you!!! |
This file contains hidden or 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
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.
After Baltic Ruby and getting to talk to people about mruby there I decided to put some work in and started looking at how I could contribute to the project!
I started running optcarrot to find easy to fix perfomance issues in the profiler, and managed to make
mrb_iv_getabout 20% faster which in total speeds up that particular benchmark by about 2% on my M2 Mac Mini with only minor code changes. But since that code path should be hot in most cases it is probably worth it?The two core changes are as follows
MRB_VTYPE_FOREACHso that the compiler can convertobj_iv_pinto a range check, this seems to be the only place where this makes a big difference to performance so it felt worth it.mrb_typefor use inobj_iv_pthat ignores boxed types since they cannot have instance variables anyhow.I am not sure if
mrb_unboxed_typeis a good name though, I feel like it isn't but it might be good enough?There are small gains with NaN boxing too, but they are a bit smaller.
Before patches, word boxing (M2 Mac Mini, macOS 14.5)
Five normal runs
fps: 32.9310863275488
fps: 32.9696898237091
fps: 32.9290379935791
fps: 32.9442253316467
fps: 32.930724759119
Three instrumented runs
The performance counters from Instruments here are not very useful to be honest but I included them since I pulled them out anyhow. Note that the percentages are the percentage of the total in the entire run.
After patches about 2% faster, word boxing (M2 Mac Mini, macOS 14.5)
Five normal runs
fps: 33.4577465475324
fps: 33.3409894683935
fps: 33.3799416005552
fps: 33.142213293828
fps: 33.2542619427094
Three instrumented runs
Ps. Thanks everyone for the cool work on mruby!