Linux 6.5 To Boast Improved Handling For Intel Hybrid CPUs With Hyper Threading

[Paradigm Shifter]

Games that spawn lots of threads, e.g. CP77 or Spiderman Miles Morales with maxed out RT, get faster with active e-cores.

Don't things which use lots of threads get faster if you give them more things to run threads on? So the same can be said of increasing the P-core count.

[abott]

HT/SMT is relatively cheap to implement and bestows an additional ~30% performance benefit. Why would you remove free performance?

You are exactly correct. HT's work on the same data pool as the main threads, and the functions that helpo implement the "2nd" thread is shadow registers, and the same checks the core uses anyway. A HT is nearly FREE performance for super small footprint. Adding ECores isn't even CLOSE to helping. A E-Core holds a lock you want on a P-Core? Haha, good luck, your P-Core is now at the will of your E-Core. Plus, compilers are made to thread nearly every damn task out there, as hinted on in Avis's message here.

You guys saying E-Cores are cheaper/better than hyper threads have not a single clue of how these chips actually work. Or programming. Or anything of what is actually going on in the chips. Literally, not a clue.

[Joe2021]

You are exactly correct. HT's work on the same data pool as the main threads, and the functions that helpo implement the "2nd" thread is shadow registers, and the same checks the core uses anyway. A HT is nearly FREE performance for super small footprint. Adding ECores isn't even CLOSE to helping. A E-Core holds a lock you want on a P-Core? Haha, good luck, your P-Core is now at the will of your E-Core. Plus, compilers are made to thread nearly every damn task out there, as hinted on in Avis's message here.

You guys saying E-Cores are cheaper/better than hyper threads have not a single clue of how these chips actually work. Or programming. Or anything of what is actually going on in the chips. Literally, not a clue.

Spending 1/3 of your text to claim that people - who actually are just discussing a topic - with different opinion do not have a clue does not make it more convincing...

Yes, what you said about locking is actually a point for SMT, but the impact depends on the workload. Anyways, no word about power envelope and costs for mitigations renders this to a single aspect, but not a complete picture.

Future will tell.

[microcode]

Wouldn't it be best to remove HT from silicone completely, since with bit.LITTLE-Designs this approach is quite pointless as you have enough threads with E-Cores anyways? This would speed up the P-Cores even more by simplification of design while also getting rid of some vulnerabilities AFAIK...

Hyperthreading has a separate power advantage, and they do well on different workloads.

[pieman]

Wouldn't it be best to remove HT from silicone completely, since with bit.LITTLE-Designs this approach is quite pointless as you have enough threads with E-Cores anyways? This would speed up the P-Cores even more by simplification of design while also getting rid of some vulnerabilities AFAIK...

i was thinking the same thing. buildzoid of actual hardcore overclocking did a video where he tested his 13900k with smt off and on. it was a massive drop in power consumption and temps, multi-thread took a hit, but it was still faster than a 13700k, and same single threaded performance as a normal 13900k with smt on. the power consumption drop and heat was really significant reduction. it was pulling under 200 watts at full bore and topping off around 70c rather than pegging close to 100c. he wondered the same thing about why intel didn't disable smt with the high e core counts.

i keep smt enabled with my 13700kf since i only have 8 e cores, but if i had a 13900k i would seriously consider just disabling it.

[abott]

who actually are just discussing a topic

They're actually just posting stupid bullshit that you would see on normal gaming sites which has no basis in reality. If you're mad about me calling it out, see the door.

[unwind-protect]

Wouldn't it be best to remove HT from silicone completely, since with bit.LITTLE-Designs this approach is quite pointless as you have enough threads with E-Cores anyways? This would speed up the P-Cores even more by simplification of design while also getting rid of some vulnerabilities AFAIK...

Well HT is absent from ARM and RISC-V, so there is a point there somewhere.

However, many workload won't have "enough" threads anytime soon, for example compiling the Linux kernel, FreeBSD `make world` or rebuilding LLVM. They easily take 50+ hardware threads when available.