<div dir="auto">Ah, let me add this, thanks to your conclusions: this is the fundamental effect of user space threads actually, because assuming even the same number of noisy C2 threads, if we did had N platform threads they would have context switch granting a fair distributed progress (latency wise), while with N virtual ones...nope, because the OS scheduler doesn't know about them and can just context switch its carriers, which can just resume the same exact current mounted virtual one, instead of interleaving them...</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il dom 15 ott 2023, 16:31 Francesco Nigro <<a href="mailto:nigro.fra@gmail.com">nigro.fra@gmail.com</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto">For HT I am not that negative, but given that x86 cannot extract enough ILP and perform all sort of tricks to keep th e CPU pipeline busy (to not mention the variable sized instr forcing to add all sort of caching), having SMT seems to be the solution of an arch problem (oversubscription to achieve full utilization, which is fun?), to squeeze the most out of it. Having separate interrupt controller too means being able to handle interrupts separately, which is not a bad thing for I/O driven workloads too (but I have to refresh my memory on this, I could be very wrong).</div><div dir="auto"><br></div>What you have discovered is interesting and valuable, which is the same problem of the so called cpu-usage metrics (broken regardless) especially because it consider a logical core on par of a full fat one...similarly, the JVM heuristics based their assumptions considering all cores to be "equals", but funny enough, with new p/e cores this thing is even more invalid than it has been for HT. Thanks for sharing this :)<div dir="auto"><br></div><div dir="auto">I can reiterate: If you collect the CPU profiling data with async-profiler, per thread (-t) you would end spot it in one go :P</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il dom 15 ott 2023, 16:09 Michael van Acken <<a href="mailto:michael.van.acken@gmail.com" target="_blank" rel="noreferrer">michael.van.acken@gmail.com</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">Am So., 15. Okt. 2023 um 14:09 Uhr schrieb Francesco Nigro <<a href="mailto:nigro.fra@gmail.com" rel="noreferrer noreferrer" target="_blank">nigro.fra@gmail.com</a>>:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>To echo what <span class="gmail_chip gmail_plusreply" dir="auto"><a href="mailto:rengels@ix.netcom.com" style="color:rgb(17,85,204);text-decoration:underline" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">@robert engels</a></span><span> said, </span><a href="https://www.moreno.marzolla.name/teaching/HPC/vol6iss1_art01.pdf" rel="noreferrer noreferrer noreferrer" target="_blank">https://www.moreno.marzolla.name/teaching/HPC/vol6iss1_art01.pdf</a> which is a bit old, but relevant enough..</div><div dir="auto">From my understanding, the workload where cache misses are a factor, HT can be beneficial, because the CPU can keep on feeding the CPU frontend (or experience less L3 transitions because 2 SMP thread can share the same data, actually). Sadly both cache misses and computational intensive tasks are both considered CPU-bound scenarios, while tbh they can be frontend/backend bound instead, and although not I/O intensive, if backend-bound, HT can boost VT workload, but just because due to the nature of workload...</div><div dir="auto">That's why I suggest (for exploration) to use a proper profiler which can report cache misses or specific CPU events. <br></div></div></blockquote><div><br></div><div>I've seen HT described as a cheap means (with regard to transistor count or chip area) to push some workloads/benchmarks higher.  Such a cost/benefit analysis probably makes sense for a consumer CPU like this one.</div><div><br></div><div>For this reason I'm not surprised that HT does not deliver much upside or downside for my workload.  Memory access patterns of compilers tend to be irregular anyway.  What brought this situation to my attention was the considerable additional resource consumption when HT is enabled.  But this seems to be only the result of a c1/c2 compilation ergonomics decision on JVM startup, caused by counting "HT cores" as "full cores".</div><div><br></div><div>The CPU events recorded by async-profiler support this story:</div><div><br></div><div>8+0+0: 41750 samples total, with 23160 (55.47%) under CompileBroker::compiler_thread_loop()</div><div>8+8+0: 78431 samples total, with 54435 (69.40%) under CompileBroker::compiler_thread_loop()</div><div><br></div><div>The additional resources spent on compilation do not pay off here, neither in the first nor over 200 iterations, and they even cannibalize the work virtual threads could be doing for the application instead.</div><div><br></div><div>-- mva</div><div><br></div></div></div>
</blockquote></div>
</blockquote></div>