-
Notifications
You must be signed in to change notification settings - Fork 273
Enable HASH_CODE by default to avoid repeated hash computation [blocks: #3486] #1992
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
@tautschnig could you explain why using |
Yes, it's the reduce-dt-size bit. But it's not about going from a vector to a list (which as of C++ is three pointers as well), but instead about going from a |
Ah, got you, I thought |
In fact it appears |
23fea45
to
6a87c26
Compare
ca5192a
to
e42bd66
Compare
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 PR failed Diffblue compatibility checks (cbmc commit: e42bd66).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/106400003
Status will be re-evaluated on next push.
Common spurious failures include: the cbmc commit has disappeared in the mean time (e.g. in a force-push); the author is not in the list of contributors (e.g. first-time contributors); compatibility was already broken by an earlier merge.
@peterschrammel @allredj Any idea why this is failing TG builds? |
Never mind, @smowton confirmed that TG already builds with |
I favour |
Fair point, will include this change in the next push to this branch. |
Commit message updated to include data points: On some SV-COMP benchmark categories, hashing accounts for >20% of CPU
For ReachSafety-ECA it's only 4.7%, which still amounts to 3006.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.
HASH_CODE
is one of those things we probably should have been doing for some time. If it doesn't work / has performance regressions then we should fix it and I think it should be fixable.
Semi-related : given all of the work on tidying up the constructors for exprts and the like. How far are we from making dt
s immutable?
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.
✔️
Passed Diffblue compatibility checks (cbmc commit: 63081a5).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/106523249
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.
Your #ifndef
actually doesn't permit manual override -- you need to do like
#ifndef HASH_CODE
 # define HASH_CODE 1
 #endif
...
#if HASH_CODE == 1
At the moment since all the tests just use #ifdef
there is in practice no way to override with -D
63081a5
to
17a4c89
Compare
Good catch - that's now fixed! |
17a4c89
to
abcb3c3
Compare
Marking do-not-merge until we have bisected a possible performance regression and also gathered feedback on this change from customers. |
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 PR failed Diffblue compatibility checks (cbmc commit: abcb3c3).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/108705935
Status will be re-evaluated on next push.
Common spurious failures include: the cbmc commit has disappeared in the mean time (e.g. in a force-push); the author is not in the list of contributors (e.g. first-time contributors); compatibility was already broken by an earlier merge.
Customer feedback indicates that the degree of performance improvement may vary, but there are no red flags. Will merge as once CI completes its work. |
On some SV-COMP benchmark categories, hashing accounts for >20% of CPU time (with profiling enabled) - top five: * ReachSafety-BitVectors: 29.29% (470.54 seconds, which reduces to 4.39 seconds; for benchmarks not timing out we save 170 seconds (25%) in non-profiling mode) * Systems_BusyBox_NoOverflows: 27.98% (284.15 seconds, which reduces to 1.74 seconds; for the 1 benchmark not timing out we save 23 seconds (6%) in non-profiling mode) * Systems_BusyBox_MemSafety: 24.24% (194.74 seconds, which reduces to 0.93 seconds; no measurable difference on the 2 benchmarks not failing/timing out) * NoOverflows-Other: 18.84% (1127.61 seconds, which reduces to 23.57 seconds; for benchmarks not timing out we save 5 seconds (7%) in non-profiling mode) * ReachSafety-ControlFlow: 17.75% (1194.04 seconds, which reduces to 29.17 seconds; for benchmarks not timing out we save 200 seconds (25%) in non-profiling mode) For ReachSafety-ECA it's only 4.7%, which still amounts to 3006.7 seconds. With this change this reduces to 323.07 seconds. On ReachSafety-ECA, this enables 3055.35 symex_step calls per second over 2752.28 calls per second without this change.
On SV-COMP benchmarks, hashing accounts for >22% of CPU time (with
profiling enabled).
Do not merge: profiling data to be supplied and further improvements to SUB_IS_LIST are in the queue.