tool idea: optimization simulator

[michaelwoerister]

It would be useful to have a tool that can simulate the impact of a hypothetical optimization to a function/query. For example, let's say someone has an idea that allows speeding up typeck_tables_of by 10% but it's kind of complicated and they don't know if they should put in the effort of implementing it. With all the caching going on in the compiler it is non-trivial to predict the effect of such an optimization on total compilation time.

However, given a concrete profile, it should be possible to compute an approximation of the same profile with the hypothetical speed-up applied. For the single-threaded case it should be pretty accurate even.

[davidbarsky]

A talk at last week's Strangeloop titled "Performance Matters" covered coz-profiler that's kinda magical—it finds and predicts what sort of optimizations would be useful, and how much of a throughput/latency increase it would provide, depending on mode the user runs coz in.

It works on C and C++, but speaking to the author and looking at coz.h, getting Rust support should be relatively easy. I think a decent starting point would be a coz-sys crate that binds against coz's headers.

[bjorn3]

Once libstd switches to parking-lot for mutexes, coz won't work correctly anymore, as it expects pthread mutexes.

[davidbarsky]

@bjorn3: oh, that's a bummer, but that's good to know. I'm guessing that requires changing coz to support parking-lot's mutexes?

[yoshuawuyts]

A way Solaris has worked around this in the past to support both pthread and non-pthread mutexes was to introduce static tracepoints called "mutex probes".

Tools such as plockstat were built around them to report on all mutex usage on the system. Perhaps we may want to consider introducing something similar so our mutexes can continue to be instrumented.

note: I've never used Solaris; all I know is anecdotal from: "Systems Performance: Enterprise and the Cloud" (Gregg, 2013)