bootstrap/format: send larger batches to rustfmt

[RalfJung]

This helps on systems with low core counts. To benchmark this I made a lot of files be modified:

for FILE in $(find compiler/ -name "*.rs"); do echo "// end of the file" >>$FILE; done

Then I ran

hyperfine "./x.py fmt -j1" -w 1 -r 4

Before this patch:

Benchmark 1: ./x.py fmt -j1
  Time (mean ± σ):      3.426 s ±  0.032 s    [User: 4.681 s, System: 1.376 s]
  Range (min … max):    3.389 s …  3.462 s    4 runs

With this patch:

Benchmark 1: ./x.py fmt -j1
  Time (mean ± σ):      2.530 s ±  0.054 s    [User: 4.042 s, System: 0.467 s]
  Range (min … max):    2.452 s …  2.576 s    4 runs

[rustbot]

r? @clubby789

rustbot has assigned @clubby789.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Urgau]

Did you try with std::thread::available_parallelism ? Did it make a difference ?

[RalfJung]

This code quite deliberately honors -j, I think. -j already defaults to available_parallelism.

On my system, available_parallelism is 20, so that just means we're no longer measuring what happens on low-core systems.

[clubby789]

@bors r+ rollup

[bors]

📌 Commit c54d92c has been approved by clubby789

It is now in the queue for this repository.

[the8472]

On my system, available_parallelism is 20, so that just means we're no longer measuring what happens on low-core systems.

The batch size was set to a small value because it might end up distributing work unevenly across rustfmt processes and thus lead to worse wall-time on many-core systems.
Have you measured the impact without -j 1?

Additionally, very little hardware with only a single core exists these days, so I think something like -j 4 would be more realistic.

Have you tried smaller increments than jumping from 8 to 64?

[RalfJung]

Without -j1 it's the same up to noise:
Before:

Benchmark 1: ./x.py fmt
  Time (mean ± σ):     841.1 ms ±  25.1 ms    [User: 7214.1 ms, System: 1635.5 ms]
  Range (min … max):   804.1 ms … 860.0 ms    4 runs

After:

Benchmark 1: ./x.py fmt
  Time (mean ± σ):     851.2 ms ±  13.4 ms    [User: 6079.3 ms, System: 545.0 ms]
  Range (min … max):   832.0 ms … 861.1 ms    4 runs

I think in most cases it'll be much less than 63 files since the formatting workers will be draining the queue faster than the directory walker fills it. I haven't tried to measure that though.

Have you tried smaller increments than jumping from 8 to 64?

I incremented it until there was no significant improvement with -j1 any more. (For the next step, to 128, I also increased the queue size since if the queue is capped at 128 even with two workers it seems unlikely they will both get 128 jobs.)

[the8472]

Ok, sounds good.

[the8472]

Actually, how did you benchmark this? I'm currently looking at the bootstrap rustfmt code and its behavior depends on the git state.
If you're on a clean master then it checks everything.
If you're on a branch or you have modified any files it only checks modified files.

This can taint benchmark results.

Edit, nevermind, I see you modified the files.

do echo "// end of the file" >>$FILE; done

[RalfJung]

Please read the PR description, I described my benchmarking methodology. :)