Skip to content

Memory regression test [blocks: #2035] #1971

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

Closed

Conversation

tautschnig
Copy link
Collaborator

This is a first proof of concept that should help spotting differences in heap memory usage. CPU performance benchmarking does not necessarily provide sufficient insight as discussed in #1855 and #1860.

@tautschnig tautschnig self-assigned this Mar 25, 2018
@tautschnig tautschnig force-pushed the memory-regression-test branch 4 times, most recently from 9d6ecda to b3b98a6 Compare March 26, 2018 09:11
data_seq.append(
snapshot(data['snapshots'][rd], rd == peak_index))

diff = color_diff(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While colour diff output is pretty and a neat feature, could we make it fallback gracefully to non-colourised output when, e.g. the output terminal doesn't support colour (rare these days) or the output is piped to a file?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, I think. (Colorama knows how to do this, and I've now hacked that into the ColorFallback code as well.)

.travis.yml Outdated
- stage: Test different OS/CXX/Flags
os: linux
compiler: gcc
cache: ccache
env:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the reason for disabling ccache here? You changed this config to be a Debug build, but you can still use ccache with that if you increase the ccache size to 2G just for this configuration.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that ok to do? Surely happy to do that, I was actually hoping for your input on that ;-)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I'd much rather have ccache enabled and bump it's size just for this config than not have it enabled (it'll make saving the cache back a bit slower, but you'll more than win that back with the build time improvements :-) )

.travis.yml Outdated
- ccache -z
- ccache --max-size=1G
- cmake -H. -Bbuild '-DCMAKE_BUILD_TYPE=Release' '-DCMAKE_CXX_COMPILER=/usr/bin/g++-5'
- cmake -H. -Bbuild '-DCMAKE_BUILD_TYPE=Debug' '-DCMAKE_CXX_COMPILER=/usr/bin/g++-5'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you want/need Debug here, or would RelWithDebInfo be a closer representative of the memory performance of a release build?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably true - will use that!

@tautschnig tautschnig force-pushed the memory-regression-test branch 2 times, most recently from 2688772 to 27e794f Compare March 26, 2018 11:10
@tautschnig tautschnig force-pushed the memory-regression-test branch 4 times, most recently from 8e8a19b to edcf5c2 Compare March 26, 2018 18:14
@tautschnig
Copy link
Collaborator Author

This appears to work reliably now. Reviews would be appreciated.

Copy link
Contributor

@chrisr-diffblue chrisr-diffblue left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!

@tautschnig
Copy link
Collaborator Author

Just one heads-up: it seems this regression test is now stable when run on an unmodified code-base. The memory-profile matching is fuzzy, but might not yet be sufficiently fuzzy to accept all negligible differences. I will have to work on this once it is merged and spuriously failing PRs arise.

@forejtv
Copy link
Contributor

forejtv commented Apr 13, 2018

@tautschnig I am not too excited about having a subdirectory with an alternative license. Where does the script come from? Any chance we could use it under the standard CBMC license?

@chrisr-diffblue
Copy link
Contributor

I haven't gone to look what other licenses we have inside the CBMC repo, but if we're going to have mixed license like this, is there an argument for putting all the files that are separately licensed under their own directory hierarchy - e.g a 'contrib' or 'external' directory at the top level of the CBMC repo? Or treat these files like mini-sat, where they get downloaded rather than imported into the repo? I'm not personally hugely concerned either way, but it would make things clearer if all the 'non CBMC license' stuff was more obviously separated.

@tautschnig
Copy link
Collaborator Author

As far as I'm aware we have got:

  • scripts/cpplint.py: Copyright Google Inc; BSD 3-clause license
  • src/big-int/*: Copyright Dirk Zoller; public domain
  • src/miniz/*: Copyright RAD Game Tools, Valve Software, Rich Geldreich, Tenacious Software LLC; MIT license
  • src/nonstd/optional.hpp: Copyright Martin Moene; MIT license
  • src/util/sorted_vector.h: Copyright Martin Holzherr; MIT-like license (Remove utilities that never got used #2019 proposes to remove this file)
  • unit/testing-utils/catch.hpp: Copyright Two Blue Cubes Ltd; Boost Software License (almost the same as MIT)

@tautschnig tautschnig force-pushed the memory-regression-test branch 4 times, most recently from 651b607 to 1d90a73 Compare April 17, 2018 22:51
Just import the minimum required for our future use from
https://github.com/MathieuTurcotte/msparser at 8ce7336d9b55366. This code is MIT
licensed (license information included).
This tool will enable memory regression tests by comparing heap memory profiles
generated using valgrind's Massif tool (or any other tool that can generate
compatible output).
@tautschnig tautschnig force-pushed the memory-regression-test branch from 1d90a73 to eb94fce Compare April 17, 2018 23:52
The CMake build configuration is now set to RelWithDebInfo to obtain usable
function call names in the heap trace. As this yields different and larger
binaries, ccache's cache size is increased to 2G for this stage.
@tautschnig
Copy link
Collaborator Author

Back to reviewers: not sure what the status on licenses is, otherwise this has now seen the following improvements: 1) The memory regression test is non-fatal to make sure its somewhat experimental nature doesn't cause inadvertent blocking. 2) The diff script now is fuzzy in its matching so that the the varying number of snapshots that massif generates does not cause havoc each time. 3) I have experimented with Google perftools and heaptrack and have neither found either of them more deterministic nor more insightful; on the contrary, massif still produces the most reliable memory profiles.

Copy link
Contributor

@NathanJPhillips NathanJPhillips left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't know enough about memory profiling, Python or Yaml to contribute a useful review however I approve of the efforts to introduce memory profiling to CBMC.

- ccache --max-size=1G
- cmake -H. -Bbuild '-DCMAKE_BUILD_TYPE=Release' '-DCMAKE_CXX_COMPILER=/usr/bin/g++-5'
- ccache --max-size=2G
- cmake -H. -Bbuild '-DCMAKE_BUILD_TYPE=RelWithDebInfo' '-DCMAKE_CXX_COMPILER=/usr/bin/g++-5'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have these two changes accidentally escaped here from other work?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, they are intentional; the commit message tries to call them out, but it might not be sufficiently clear?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can confirm that this was an intentional change that @tautschnig and I
discussed in an earlier part of this PR.

Copy link
Collaborator

@martin-cs martin-cs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not going to comment on the licensing issues but massif is my tool of choice for heap profiling CPROVER and having a regular, automated run of it would be A Good Thing.

Copy link
Member

@peterschrammel peterschrammel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Putting the MIT-licensed test utility scripts into a separate directory is ok.

@tautschnig tautschnig changed the title Memory regression test Memory regression test [blocks: #2035] Nov 10, 2018
@TGWDB
Copy link
Contributor

TGWDB commented May 19, 2021

Closing this this is very out of date and apparently untouched. The blocker appears to no longer be true. Please reopen and redo for new CI system if you believe this is erroneous.

@TGWDB TGWDB closed this May 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants