Re: RTS changes affect runtime when they shouldn’t

[Sven Panne]

2017-09-26 18:35 GMT+02:00 Ben Gamari <ben at smart-cactus.org>:

> While it's not a bad idea, I think it's easy to drown in information. Of
> course, it's also fairly easy to hide information that we don't care
> about, so perhaps this is worth doing regardless.
>

The point is: You don't know in advance which of the many performance
characteristics "perf" spits out is relevant. If e.g. you see a regression
in runtime although you really didn't expect one (tiny RTS change etc.), a
quick look at the diffs of all perf values can often give a hint (e.g.
branch prediction was screwed up by different code layout etc.).

So I think it's best to collect all data, but make the user-relevant data
(runtime, code size) more prominent than the technical/internal data (cache
hit ratio, branch prediction hit ratio, etc.), which is for analysis only.
Although the latter is a cause for the former, from a compiler user's
perspective it's irrelevant. So there is no actual risk in drowning in
data, because you primarily care only for a small subset of it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170927/e9fd20b9/attachment.html>