-
Notifications
You must be signed in to change notification settings - Fork 281
Eliminate usage of volatile variables used to prevent dead code elimination #1447
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
Conversation
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.
Thank you @adamsitnik for doing this!
{ | ||
VolatileObject = obj; | ||
} | ||
private static void Escape(object _) { } |
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.
should we have a common Escape()
method that can be used everywhere?
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.
Also, just to confirm, have you verified the disasm to make sure this does what we intent to do?
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.
Also, just to confirm, have you verified the disasm to make sure this does what we intent to do?
Passing an object to a method that can't be inlined is an old trick used even by GC.KeepAlive
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.
should we have a common Escape() method that can be used everywhere?
I would prefer to stick with the current guidelines that basically say that all you need to do to prevent from dead code elimination is to return the result from the benchmark and BDN is going to consume it for you
when I was porting the benchmarks long time ago I was asked to not rerwrite them, this is the only reason why this old benchmark is still using this old pattern.
Could you please also update this portion of "Microbenchmark Design Guidelines" to reflect the guidance? |
fixes #1444
The reported timings can only decrease, so this change should not trigger a regression in the auto-filing issue