-
Notifications
You must be signed in to change notification settings - Fork 68
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
Fix/speed regression #705
Fix/speed regression #705
Conversation
Prepare release 10.0.7
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good!
cogit cog: newMethod selector: objectMemory nilObject. | ||
methodHeader := self rawHeaderOf: newMethod ] | ||
ifFalse: [ self maybeFlagMethodAsInterpreted: newMethod ] ]. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good, do not compile on method activation
instructionPointer := cogit ceReturnToInterpreterPC]. | ||
^ self activateCoggedNewMethod: inInterpreter]. | ||
|
||
"We are in the interpreter" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, activate compiled method if already compiled
"if not primitive, or primitive failed, activate the method" | ||
self activateNewMethod ] | ||
] | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the major change in here, now this method can be parametrised to eagerly compile methods (or not). By default the interpreter will not do it.
Thanks for the explanation @guillep |
Just to give some more details (@guillep editing here):
This release fixes a regression introduced during a refactoring.
The refactoring introduced accidentally an eager compilation of methods to machine code and reduced the number of JIT'ted methods activated.
This provoked, on the one hand, spending extra time on compiling useless methods and trashing the machine code cache, and on the other hand, an over-reliance on the interpreter interpreter.
This PR re-introduces those heuristics while keeping the refactoring (that removed lots of duplicated code).
This week we worked also on moving forward the benchmarking infrastructure to be able to eagerly detect these kind of issues in the future. See the list of benchmarks below showing the performance of a couple of benchmarks for VMs version 10.0.4 (default in Pharo 10), 10.0.7 (default in Pharo 11) and 10.0.8 (10.0.7 + this fix).
Interestingly, the regression only affects two benchmarks but very markingly: see column 10.0.7.
Also, since 10.0.7 we have a slight improvement in reverse complement and file benchmarks, probably due to ephemerons and GC improvements.