<div dir="ltr">Hello,<div><br></div><div>I have the strange situation that *disabling* hyperthreading on a two year old Intel Alder Lake system (8 performance cores, 4 efficiency cores) gives me a speedup of 1.2 for one particular use case.</div><div><br></div><div>The scenario is a compiler bootstrap, with namespaces running as virtual threads delegating  compilation of individual functions to dedicated virtual threads.  All in all very unstructured concurrency, and not an experiment I would ever have contemplated without Loom's virtual threads.  This attempt to go wide with the number of concurrent tasks (maybe 2k in total) has a positive effect on overall runtime, but it's not dramatic and even less so if hyperthreading is enabled.</div><div><br></div><div>I first noticed the runtime discrepancy a year ago, and before upgrading Ubuntu this morning I took the chance to compare their 6.2.0-34 kernel with 6.5.0-9.  Averaging bash's time over 10 runs of the java process and booting Linux both without and with nosmp set, I got this:</div><div><br></div><div>6.2.0-34 -- default 1.49s --> nosmp 1.21s for a speedup of 1.23</div><div>6.5.0-9 -- default 1.44s --> nosmp 1.20s for a speedup of 1.20</div><div><br></div><div>The default setup reports 20 logical cpus, while nosmp reduces this to 12.  I doubt that this particular workload comes even close to utilizing 20 logical cpus, so not much upside is to be expected by having the 8 additional logical cpus.  But at some time in the past I tried this on an older machine with 4 cores/8 threads, and there the additional logical cores were very beneficial -- as expected.</div><div><br></div><div>What baffles me is the significant downside when going from 12 nosmp cores to 20 with smp.  What can make this workload so sensitive to hyperthreading?  Has anyone seen something similar?</div><div><br></div><div> -- mva</div><div><br></div></div>