Stream: t-compiler/wg-parallel-rustc

Topic: concerns

nnethercote (May 08 2019 at 06:00, on Zulip):

One thing that worries me about the parallel compiler is that it will make profiling and benchmarking harder.

nnethercote (May 08 2019 at 06:01, on Zulip):

Instruction count is the metric with the least variance, by a long way. Currently it correlates well with wall time, which is the true metric of concern (i.e. what users observe). In a parallel compiler, that correlation will be greatly weakened.

nnethercote (May 08 2019 at 06:02, on Zulip):

As a result, our ability to detect small regressions (and improvements) to compiler performance will be harmed.

nnethercote (May 08 2019 at 06:03, on Zulip):

More generally, the use of coarse-grained parallelism in compilers is well-established and is known to work well. But I'm worried about fine-grained parallelism. The perf numbers I've seen so far have had some good improvements on some workloads, but also some drastic regressions on others.

mw (May 08 2019 at 15:25, on Zulip):

I agree that fine-grained parallelism in a compiler is a mostly uncharted field. I wonder what it would look like if we went for a more traditional approach (which usually scales better to distributed compilation).

mw (May 08 2019 at 15:26, on Zulip):

On the other hand, we should soon be in a position to do a real world evaluation of a compiled with fine-grained parallelism built in, which is pretty interesting.

mw (May 08 2019 at 15:28, on Zulip):

regarding profiling: the compiler will still allow being locked to only one thread, which should make the correlation between instruction count and wall-time greater again. Maybe we should keep collecting numbers for single-thread runs in order to make detection of regressions easier?

lwshang (May 08 2019 at 19:34, on Zulip):

Agree with @mw about regression detection. We can always constraint with one thread to make the performance comparison meaningful.

About profiling, I'm not quite sure whether it refers to profile the compilation using rustc? Is such profiling useful?

nnethercote (May 08 2019 at 20:02, on Zulip):

We should measure what we ship. I'm worried that measuring single-thread runs would be misleading if we are shipping a multi-threaded compiler.

Vadim Petrochenkov (May 08 2019 at 21:28, on Zulip):

Isn't multi-threaded codegen already enabled in rustc by default?
Do perf runs disable it (thus decreasing variance) or not (thus not measuring what we ship)?

simulacrum (May 08 2019 at 21:29, on Zulip):

I believe that we do not disable parallel codegen

mw (May 09 2019 at 09:17, on Zulip):

We definitely should measure what we ship. But single-threaded runs could be done in addition in order to have improved regression detection.

Last update: Mar 30 2020 at 23:45UTC