<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">In my HFT experience we never used HT cores. It was almost always slower. </div><div dir="ltr"><br></div><div dir="ltr">Here’s why. The kernel scheduler job is to allocate work to cores. The more cores the more management is has to do (context management) Usually this is ok because the increased number of cores runs more work. </div><div dir="ltr"><br></div><div dir="ltr">The latter point may not hold based on workload. The OS does not have visibility into what the work profile for a particular thread is - so if it scheduler essentially identical workloads (e.g all integer or all floating point) on two logical cores (same physical core) the physical can’t fully parallelize them (since they use the same components - typically is one core is blocked waiting on memory the other core can run a computation, etc)</div><div dir="ltr"><br></div><div dir="ltr">The end result is that the OS spends extra effort managing the work with no gain = slower. </div><div dir="ltr"><br></div><div dir="ltr">My suggestion is to always turn off HT. </div><div dir="ltr"><br></div><div dir="ltr">Note that HT is very different on some architectures like RISC where the simple instructions and the pipeline make it easier to parallelize via shifting. </div><div dir="ltr"><br><blockquote type="cite">On Oct 15, 2023, at 5:11 AM, Francesco Nigro <nigro.fra@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="auto">I suggest to use a profiler which can show more than the java side here, async profiler.<div dir="auto">But please beware the suggestion <a href="https://github.com/async-profiler/async-profiler/issues/779#issuecomment-1651104553">https://github.com/async-profiler/async-profiler/issues/779#issuecomment-1651104553</a> from one of the Loom team's member.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il mer 11 ott 2023, 18:54 Michael van Acken <<a href="mailto:michael.van.acken@gmail.com">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">Given the huge difference of a factor of 2 in user time between the default and the nosmt setup, I tried to use jfr to find some metric that differs markedly between the two. The workload is the same: the very same task is executed leading to the expected result. This time it's 300 back to back compilations within a single java process. Using the threadId() of a final virtual thread as proxy, ~570k threads seem to be utilized overall.<br><br>"jfr view hot-methods" does not show any significant difference, with the top entry being ForkJoinPool.awaitWork() at around 5.5% in both cases.<br><br>But "jfr view latencies-by-type" shows a large difference in its Total column for "Java Thread Park". Could this be a clue where the user time accumulates?<br><br>### with "nosmt"<br><br>real 77.67<br>user 468.16<br>sys 13.48<br><br>jfr view latencies-by-type recording.jfr<br> Latencies by Type<br><br>Event Type Count Average P 99 Longest Total<br>-------------------------------------- ------ ------- ------- ------- ---------<br>Java Thread Park 18.651 36,9 ms 310 ms 2,88 s 11 m 43 s<br>File Write 2 11,7 ms 12,6 ms 12,6 ms 23,4 ms<br><br>### default (without "nosmt")<br><br>real 93.60<br>user 824.12<br>sys 23.08<br><br>jfr view latencies-by-type recording.jfr<br> Latencies by Type<br><br>Event Type Count Average P 99 Longest Total<br>--------------------------------------- ------ ------- ------- ------- --------<br>Java Thread Park 30.263 45,7 ms 256 ms 504 ms 23 m 2 s<br>File Read 1 10,9 ms 10,9 ms 10,9 ms 10,9 ms</div><div dir="ltr"><br></div></div>
</blockquote></div>
</div></blockquote></body></html>