4 ms·

> Intel will move to a new approach with its P-Cores that discards hyperthreading, which allows two threads to run on a single CPU core... This makes figuring

> Intel will move to a new approach with its P-Cores that discards hyperthreading, which allows two threads to run on a single CPU core... This makes figuring out how many threads to run for optimal performance even more confusing.

yjftsjthsd-h 3y ago
Isn't that still just a matter of asking the operating system how many cores it has? My understanding is that hyperthreading shows up as CPU cores, so if the CPU doesn't have hyperthreading it just won't show up as having that many cores.
- astrodust 3y ago
  Except in this case 1 P core can handle 2 threads, while before 1 P core shows up as 2 "cores", so the math is easier.
toast0 3y ago
Not having to worry about if hyperthreading helps or hurts should make it less confusing. If your threads are cpu-busy, run one thread per core and you're done. If your threads are io-busy, pick thread counts based on io limits (depending on where on the throughput/latency spectrum you fall) If you've got P and E cores, you might need to do some perhaps new stuff to balance threads --- the old way where an e core was about half the perf of a P core, so two threads on P and one on E was kind of even won't work without hyperthreads, but if you don't cpu pin your threads, maybe it works out. (Maybe the OS needs to do more work to track usage though)
- astrodust 3y ago
  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.

yjftsjthsd-h 3y ago

Isn't that still just a matter of asking the operating system how many cores it has? My understanding is that hyperthreading shows up as CPU cores, so if the CPU doesn't have hyperthreading it just won't show up as having that many cores.

astrodust 3y ago
Except in this case 1 P core can handle 2 threads, while before 1 P core shows up as 2 "cores", so the math is easier.

toast0 3y ago

Not having to worry about if hyperthreading helps or hurts should make it less confusing. If your threads are cpu-busy, run one thread per core and you're done. If your threads are io-busy, pick thread counts based on io limits (depending on where on the throughput/latency spectrum you fall) If you've got P and E cores, you might need to do some perhaps new stuff to balance threads --- the old way where an e core was about half the perf of a P core, so two threads on P and one on E was kind of even won't work without hyperthreads, but if you don't cpu pin your threads, maybe it works out. (Maybe the OS needs to do more work to track usage though)

astrodust 3y ago
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.