[PATCH] D77144: [NFC] Remove waymarking because it improves performances

Tyker via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Apr 2 03:13:52 PDT 2020


Tyker added a comment.

In D77144#1954171 <https://reviews.llvm.org/D77144#1954171>, @ekatz wrote:

> Let me shed a little light on the Waymarking algorithm:


thanks for the insight

> According to the his blog, in http://heisenbug.blogspot.com/2008/05/merged.html; I quote:
>  //"... the SPEC benchmark 447.dealII had a **13%** reduced memory footprint ..."//

i don't have access to SPEC since it isn't open source.

> and
>  //"... observed slight speedup on kimwitu++ benchmark's compilation time."//

from my an nikic's measurement this is not true anymore.

> Regarding the removal of the //Waymarking//, don't get me wrong, I am all in for its simplicity, and performance improvements, but I'm afraid more investigation needs to be done.
>  Please try to test using the benchmarks mentioned above, and maybe even larger workloads (like the linux kernel, if you can; and I know, at least it part, if not in full, the AOSP is using clang).

i ran a build of clang while tracking max memory use of every translation units (2687).
the highest max memory use difference i saw was +7.27% on llvm/lib/DebugInfo/CodeView/EnumTables.cpp.
but it is a outlier since the the second highest was at +1.80% and there are 7 other TU above 1.5%
the average over all TU was a +0.25%.
i didn't measure compile-time during this build because it measuring it accurately would have taken a very long time.

In D77144#1956725 <https://reviews.llvm.org/D77144#1956725>, @foad wrote:

> In D77144#1953469 <https://reviews.llvm.org/D77144#1953469>, @nikic wrote:
>
> > [...] at the time it was introduced, waymarking was a 2.5% compile-time regression, but saved 12% memory on some large C++ workloads. We're clearly not seeing anything close to a 12% memory regression here, but it's not clear whether that's because memory usage characteristics in LLVM changed significantly over the last 12 years (which doesn't seem unplausible) [...]
>
>
> Can we easily collect statistics on how much memory is allocated for what kind of objects? E.g. how much of the peak usage is Uses, how much is Instructions, how much is BasicBlocks and so on?


since allocation of Use is grouped with the User (and all derived classes of User) i don't think a tool could figure it out.
we could easily instrument manually every allocation of a Use to see the difference in allocation size but this wouldn't give us the difference at its peak.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77144/new/

https://reviews.llvm.org/D77144





More information about the llvm-commits mailing list