3 ms·

Except that in this case a P core being able to run two threads, but registering as one "core", means you'll need to account for that to take full use of them,

Except that in this case a P core being able to run two threads, but registering as one "core", means you'll need to account for that to take full use of them, otherwise they're only half loaded. Maybe the CPU can report how many threads it's capable of executing, regardless of how the cores are structured and their various capabilities, that'd be nice. I can imagine Intel might push this further, having 4 threads per core some day.

toast0 3y ago
In this case, the rumor says this core design no longer has hyperthreading, so a P core can't run two threads. If that's true, it seems more likely that Intel is heading towards ending multithreaded cores than going towards 4 threads per core. IMHO, more threads per core helps with interactivity at very low core counts (like 1 core), and can help with throughput by scheduling other work during memory loads, but at higher core counts, memory bandwidth is oversubscribed and you end up with both threads waiting for memory. Die space wise, it may make more sense to put in full e-cores or c cores rather than hyperthreads. And security wise, hyperthreads are a nightmare. In the case where a core can run multiple threads, you have to benchmark to see if it makes more sense to run one thread per core (and possibly disable hyperthreading) or one OS thread per cpu thread. Sometimes there's a big difference, usually it's fairly small; and it can go either way. It's not unreasonable to run one thread per cpu-thread as a default, for cpu-busy code. It's definitely not the case that if you have a core capable of running two threads that you lose half your throughput by only running a single thread. Depending on core design, you may or may not have a penalty by running single threaded and configured for two threads, if the core does a static partition of resources such as rename registers. But even in that case, losing half the rename registers is unlikely to reduce throughput by half.

toast0 3y ago

In this case, the rumor says this core design no longer has hyperthreading, so a P core can't run two threads. If that's true, it seems more likely that Intel is heading towards ending multithreaded cores than going towards 4 threads per core. IMHO, more threads per core helps with interactivity at very low core counts (like 1 core), and can help with throughput by scheduling other work during memory loads, but at higher core counts, memory bandwidth is oversubscribed and you end up with both threads waiting for memory. Die space wise, it may make more sense to put in full e-cores or c cores rather than hyperthreads. And security wise, hyperthreads are a nightmare. In the case where a core can run multiple threads, you have to benchmark to see if it makes more sense to run one thread per core (and possibly disable hyperthreading) or one OS thread per cpu thread. Sometimes there's a big difference, usually it's fairly small; and it can go either way. It's not unreasonable to run one thread per cpu-thread as a default, for cpu-busy code. It's definitely not the case that if you have a core capable of running two threads that you lose half your throughput by only running a single thread. Depending on core design, you may or may not have a penalty by running single threaded and configured for two threads, if the core does a static partition of resources such as rename registers. But even in that case, losing half the rename registers is unlikely to reduce throughput by half.