4 ms·

I'd say there's still a gap in my mental model. I agree that it's normal to observe this, definitely. I see it in other tools that utilize parallelism too. I ju

I'd say there's still a gap in my mental model. I agree that it's normal to observe this, definitely. I see it in other tools that utilize parallelism too. I just can't square the 2x overhead part of it in a workload like Cargo's, which I assume is not fine-grained. I see the same increase in user time with ripgrep too, and its parallelism is maybe more fine grained than Cargo's, but is still at the level of a single file, so it isn't that fine grained. But maybe for Cargo, parallelism is more fine grained than I think it is. Perhaps because of codegen-units. And similarly for ripgrep, if it's searching a lot of tiny files, that might result in fine grained parallelism in practice.

Filligree 4y ago
Well, like mentioned elsewhere, most of that overhead is just hyper threads slowing down when they have active siblings. Which is fine; it’s still faster overall. Disable SMT and you’ll see much lower overhead, but higher time spent overall.
- burntsushi 4y ago
  Yes, I know its fine. I just don't understand the full details of why hyperthreading slows things down that much. There are more experiments that could be done to confirm or deny this explanation, e.g., disabling hyperthreading. And playing with the thread count a bit more.
  - Filligree 4y ago
    Hyperthreading only duplicates the frontend of the CPU. That's really it. That's the entire explanation. It's useful if and only if there are unused resources behind it, due to pipeline stalls or because the siblings are doing different things. It's virtually impossible to fully utilize a CPU core with a single thread; having two threads therefore boosts performance, but only to the degree that the first thread is incapable of using the whole thing. That's why the speedup is around 20%, not 100%.
    - burntsushi 4y ago
      I know all of that. There's still a gap because it doesn't explain in full detail how contended resources lead to the specific slowdown seen here. Hell, nobody in this thread has done the experiments nexessary to confirm that HT is evem the cause in the first place.

Filligree 4y ago

Well, like mentioned elsewhere, most of that overhead is just hyper threads slowing down when they have active siblings. Which is fine; it’s still faster overall. Disable SMT and you’ll see much lower overhead, but higher time spent overall.

burntsushi 4y ago
Yes, I know its fine. I just don't understand the full details of why hyperthreading slows things down that much. There are more experiments that could be done to confirm or deny this explanation, e.g., disabling hyperthreading. And playing with the thread count a bit more.
- Filligree 4y ago
  Hyperthreading only duplicates the frontend of the CPU. That's really it. That's the entire explanation. It's useful if and only if there are unused resources behind it, due to pipeline stalls or because the siblings are doing different things. It's virtually impossible to fully utilize a CPU core with a single thread; having two threads therefore boosts performance, but only to the degree that the first thread is incapable of using the whole thing. That's why the speedup is around 20%, not 100%.
  - burntsushi 4y ago
    I know all of that. There's still a gap because it doesn't explain in full detail how contended resources lead to the specific slowdown seen here. Hell, nobody in this thread has done the experiments nexessary to confirm that HT is evem the cause in the first place.