4 ms·

Did you test at least +1 if not *1.5 or something? I would expect you to occasionally get blocked on disk I/O and would want some spare work sitting hot to swit

by saurik 2y ago

Did you test at least +1 if not *1.5 or something? I would expect you to occasionally get blocked on disk I/O and would want some spare work sitting hot to switch in.

rwmj 2y ago
Let me test that now. Note I only have 1 Intel machine so any results are very specific to this laptop. -j time (mean ± σ) 12 (#P+#E) 130.889 s ± 4.072 s 13 (..+1) 135.049 s ± 2.270 s 4 (#P) 179.845 s ± 1.783 s 8 (#E) 141.669 s ± 3.441 s Machine: 13th Gen Intel(R) Core(TM) i7-1365U; 2 x P-cores (4 threads), 8 x E-cores
- wtallis 2y ago
  Your processor has two P cores, and ten cores total, not twelve. The HyperThreading (SMT) does not make the two P cores into four cores. Your experiment with 4 threads will most likely result in using both P cores and two E cores, as no sane OS would double up threads on the P cores before the E cores were full with one thread each.
  - rwmj 2y ago
    The hyperthreading should cover up memory latency, since the workload (compiling qemu) might not fit into L3 cache. Although I take your point that it doesn't magically create two core-equivalents.
    - gonzo 2y ago
      “Hyperthreading” is a write pipe hack. If the core stalls on a write then the other thread gets run.
      - atq2119 2y ago
        It's much more than that. It also allows one thread to make progress while the other is waiting for memory loads, or filling in instruction slots while the other thread is recovering from a branch mispredict. Compilers tend to do a lot of pointer chasing and branching, so it's expected that they would benefit decently from hyperthreading.
  - jeffbee 2y ago
    I am sure rwmj was smart enough to use `taskset` to make this experiment meaningful.
    - rwmj 2y ago
      Hehe, if only :-( However I do want to know what's best with the default Linux scheduler and just using 'make' rather than more complicated commands.

by saurik 2y ago

Did you test at least +1 if not *1.5 or something? I would expect you to occasionally get blocked on disk I/O and would want some spare work sitting hot to switch in.

rwmj 2y ago

Let me test that now. Note I only have 1 Intel machine so any results are very specific to this laptop. -j time (mean ± σ) 12 (#P+#E) 130.889 s ± 4.072 s 13 (..+1) 135.049 s ± 2.270 s 4 (#P) 179.845 s ± 1.783 s 8 (#E) 141.669 s ± 3.441 s Machine: 13th Gen Intel(R) Core(TM) i7-1365U; 2 x P-cores (4 threads), 8 x E-cores

wtallis 2y ago
Your processor has two P cores, and ten cores total, not twelve. The HyperThreading (SMT) does not make the two P cores into four cores. Your experiment with 4 threads will most likely result in using both P cores and two E cores, as no sane OS would double up threads on the P cores before the E cores were full with one thread each.
- rwmj 2y ago
  The hyperthreading should cover up memory latency, since the workload (compiling qemu) might not fit into L3 cache. Although I take your point that it doesn't magically create two core-equivalents.
  - gonzo 2y ago
    “Hyperthreading” is a write pipe hack. If the core stalls on a write then the other thread gets run.
    - atq2119 2y ago
      It's much more than that. It also allows one thread to make progress while the other is waiting for memory loads, or filling in instruction slots while the other thread is recovering from a branch mispredict. Compilers tend to do a lot of pointer chasing and branching, so it's expected that they would benefit decently from hyperthreading.
- jeffbee 2y ago
  I am sure rwmj was smart enough to use `taskset` to make this experiment meaningful.
  - rwmj 2y ago
    Hehe, if only :-( However I do want to know what's best with the default Linux scheduler and just using 'make' rather than more complicated commands.