4 ms·
> Now it still seems strange (as in it looks like a performance bug) that most times rust was stuck in just one threat (instead of e.g. 8). Agreed, seems like
by lsuresh 1y ago
> Now it still seems strange (as in it looks like a performance bug) that most times rust was stuck in just one threat (instead of e.g. 8).
Agreed, seems like there are some rustc performance bugs at play here.
- steveklabnik 1y agoI haven't dug into the details, but it may not even be a performance bug, depending on how you define 'bug': the Rust compiler is not fully parallel itself yet. That's a bug in the sense of something that needs to be improved and fixed, but isn't one in the sense of "unexpected bad behavior".
- lsuresh 1y agoMakes sense. We'd appreciate some more eyeballs here for sure. Between HN and a Reddit thread, there are a few hypotheses floating around. I've shared a repro here for anyone interested: https://github.com/feldera/feldera/issues/3882 https://github.com/feldera/feldera/issues/3882
- steveklabnik 1y agoYou may want to post on the Zulip, I think that's the way to get in touch with the team these days.
- dathinab 1y agothe thing is: codegen-units defaults to 16 in release builds, and by far the most time in the "passes" list is spend in LLVM passed (which is was codegen-units parallelizes),so most times it shouldn't be stuck with 1 high load core (even if it's not 16 all the time). so it looks a lot like something is prevented the intended codegen parallelization of the crate Through it indeed might not have been a bug, e.g. before the change in generation to split it across crates source code might have been in a way where it can't split the crate into multiple units. Or maybe something made rust believe splitting it is a bad idea, e.g. related to memory usage or similar.
- steveklabnik 1y agoAh yeah, that does sound like a bug to me; it’s the earlier stages that I’m thinking of that aren’t parallel yet.