3 ms·

Re parallelism: I have 12 cores, and cargo indeed effectively uses them all. As a result, the computer becomes extremely sluggish during a long compilation. Is

by ilyagr 4y ago

Re parallelism: I have 12 cores, and cargo indeed effectively uses them all. As a result, the computer becomes extremely sluggish during a long compilation. Is there a way to tell Rust to only use 11 cores or, perhaps, nice its processes/threads to a lower priority on a few cores? I suppose it's not the worst problem to have. Makes me realize how spoiled I got after multiple-core computers became the norm.

mbrubeck 4y ago
`cargo build -j11` will limit parallelism to eleven cores. Cargo and rustc use the Make jobserver protocol [0][1][2] to coordinate their use of threads and processes, even when multiple rustc processes are running (as long as they are part of the same `cargo` or `make` invocation): [0]: https://www.gnu.org/software/make/manual/html_node/Job-Slots.html https://www.gnu.org/software/make/manual/html_node/Job-Slots... [2]: https://github.com/rust-lang/cargo/issues/1744 https://github.com/rust-lang/cargo/issues/1744 [2]: https://github.com/rust-lang/rust/pull/42682 https://github.com/rust-lang/rust/pull/42682 `nice cargo build` will run all threads at low priority, but this is generally a good idea if you want to prioritize interactive processes while running a build in the background.
- epage 4y ago
  To add, in rust 1.63, cargo added support for negative numbers, so you can say `cargo build --jobs -2` to leave two cores available. See https://github.com/rust-lang/cargo/blob/master/CHANGELOG.md#cargo-164-2022-09-22 https://github.com/rust-lang/cargo/blob/master/CHANGELOG.md#...
  - touisteur 4y ago
    Small quality of life changes like this really make the cargo and rust community shine, I feel. I'm not a heavy rust user but following all the little improvements in warnings, hints, they build up to a great experience. I wish we had the mindshare and peoplepower to do that in my language and tooling of choice (I'm specifically talking about effort and muscle, because motivation is clearly already there).
deleted 4y ago
[deleted]
globalreset 4y ago
exec ionice -c 3 nice -n 20 "$@" Make it a shell script like `takeiteasy`, and run `takeiteasy cargo ...`
- kstrauser 4y ago
  Partly because of being a Dudeist, and partly because it's just fun to say, I just borrowed this and called it "dude" on my system. dude cargo ... has a nice flow to it.
jrockway 4y ago
Are they real cores or hyperthreads/SMT? I've found that hyperthreading doesn't really live up to the hype; if interactive software gets scheduled on the same physical core as a busy hyperthread, latency suffers. Meanwhile, Linux seems to do pretty well these days handling interactive workloads while a 32 core compilation goes on in the background. SMT is a throughput thing, and I honestly turn it off on my workstation for that reason. It's great for cloud providers that want to charge you for a "vCPU" that can't use all of that core's features. Not amazing for a workstation where you want to chill out on YouTube while something CPU intensive happens in the background. (For a bazel C++ build, having SMT on, on a Threadripper 3970X, does increase performance by 15%. But at the cost of using ~100GB of RAM at peak! I have 128GB, so no big deal, but SMT can be pretty expensive. It's probably not worth it for most workloads. 32 cores builds my Go projects quickly enough, and if I have to build C++ code, well, I wait. ;)

by ilyagr 4y ago

mbrubeck 4y ago

`cargo build -j11` will limit parallelism to eleven cores. Cargo and rustc use the Make jobserver protocol [0][1][2] to coordinate their use of threads and processes, even when multiple rustc processes are running (as long as they are part of the same `cargo` or `make` invocation): [0]: https://www.gnu.org/software/make/manual/html_node/Job-Slots.html https://www.gnu.org/software/make/manual/html_node/Job-Slots... [2]: https://github.com/rust-lang/cargo/issues/1744 https://github.com/rust-lang/cargo/issues/1744 [2]: https://github.com/rust-lang/rust/pull/42682 https://github.com/rust-lang/rust/pull/42682 `nice cargo build` will run all threads at low priority, but this is generally a good idea if you want to prioritize interactive processes while running a build in the background.

epage 4y ago
To add, in rust 1.63, cargo added support for negative numbers, so you can say `cargo build --jobs -2` to leave two cores available. See https://github.com/rust-lang/cargo/blob/master/CHANGELOG.md#cargo-164-2022-09-22 https://github.com/rust-lang/cargo/blob/master/CHANGELOG.md#...
- touisteur 4y ago
  Small quality of life changes like this really make the cargo and rust community shine, I feel. I'm not a heavy rust user but following all the little improvements in warnings, hints, they build up to a great experience. I wish we had the mindshare and peoplepower to do that in my language and tooling of choice (I'm specifically talking about effort and muscle, because motivation is clearly already there).

deleted 4y ago

[deleted]

globalreset 4y ago

exec ionice -c 3 nice -n 20 "$@" Make it a shell script like `takeiteasy`, and run `takeiteasy cargo ...`

kstrauser 4y ago
Partly because of being a Dudeist, and partly because it's just fun to say, I just borrowed this and called it "dude" on my system. dude cargo ... has a nice flow to it.

jrockway 4y ago

Are they real cores or hyperthreads/SMT? I've found that hyperthreading doesn't really live up to the hype; if interactive software gets scheduled on the same physical core as a busy hyperthread, latency suffers. Meanwhile, Linux seems to do pretty well these days handling interactive workloads while a 32 core compilation goes on in the background. SMT is a throughput thing, and I honestly turn it off on my workstation for that reason. It's great for cloud providers that want to charge you for a "vCPU" that can't use all of that core's features. Not amazing for a workstation where you want to chill out on YouTube while something CPU intensive happens in the background. (For a bazel C++ build, having SMT on, on a Threadripper 3970X, does increase performance by 15%. But at the cost of using ~100GB of RAM at peak! I have 128GB, so no big deal, but SMT can be pretty expensive. It's probably not worth it for most workloads. 32 cores builds my Go projects quickly enough, and if I have to build C++ code, well, I wait. ;)