Multithreaded mode

[asomers]

--each-feature and --feature-powerset are great! My only complaint is that they are slow. bpytop shows that I'm never using more than one core when running cargo-hack. It would be awesome if cargo hack could run multiple cargo processes in parallel, one for each feature combination. Normally Cargo doesn't allow two processes to share the same build directory at the same time, so you could set CARGO_TARGET_DIR to a separate value for each.

There is a little contention for the crate cache, but my crude benchmark shows that I can build targets in parallel in about a quarter of the time it takes to build them sequentially.

[taiki-e]

I think this is a great idea. I would accept a PR to implement this.

[asomers]

I thought about it, but decided that I don't have the time to do it myself.

[NishantJoshi00]

Hey, I was looking around and it seems that this issue hasn't been addressed in quite a long time. Wanting to know, if you are still accepting PR, for this issue.

[leighmcculloch]

@NishantJoshi00 you might want to try #175 that adds a way to get a list of commands out, and then you can run those commands separately for different processes. I'm using that command to run the processes on different machines even.

[NishantJoshi00]

Interesting! I was able to come up with a similar solution for improving performance. I achieved parallelization with rayon and have a CARGO_TARGET_DIR pool to also leverage caching.
I was planning to raise a PR for this issue too.

[asomers]

This feature request is no longer as important as it was when I filed it, because rust 1.64.0 supports multitarget builds. So you can now do something like cargo hack check --target i686-linux-android --target x86_64-apple-darwin --target x86_64-apple-ios .... And cargo-hack happily passes all of those targets through to the cargo check command. That provides plenty of parallelism if you have multiple targets to care about. But it still doesn't address the case where the only parallelism comes from different feature sets.

[taiki-e]

Yeah, this is still useful and PR is welcome.

[jcgruenhage]

I think this is already mostly solved by #253, right? If anything, this needs more extensive documentation so that people don't miss it.

[taiki-e]

Yeah, especially on CI machines where there are fewer cores available, so I think --partition (#253) is the more scalable and preferred approach.

[jcgruenhage]

Should this issue be closed then?