Strange interaction with hyperthreading on Intel hybrid CPU

[Robert Engels]

Imo VT are ideal for IO bound tasks. Cpu bound tasks should use an os thread pool. 

> On Oct 10, 2023, at 10:04 AM, Michael van Acken <michael.van.acken at gmail.com> wrote:
> 
> 
>> Am Di., 10. Okt. 2023 um 15:56 Uhr schrieb Alan Bateman <Alan.Bateman at oracle.com>:
> 
>> There's a table of system properties in the java.lang.Thread javadoc with the configuration, you probably want -Djdk.virtualThreadScheduler.maxPoolSize=<N> for your testing. It's hard to know what to take from your mail as virtual thread are only going to help if most of the time is spent blocking at the queue, the compilation and class generation tasks seem very compute bound.
> 
>  [When I wrote nosmp in my original mail I meant nosm*t*.  I just found out that nosmp is also a thing, and was utterly confused to have just a single core all of a sudden.]
> 
> Timings for 20 back to back iterations inside a bash for loop of `java -Djdk.virtualThreadScheduler.maxPoolSize=n ...` gives me this:
> 
> ## without nosmt
> 
> n=20 (matching logical core count)
> real 29.57
> user 265.08
> sys 8.32
> 
> n=12
> real 29.40
> user 261.99
> sys 8.08
> 
> ## with nosmt
> 
> n=20
> real 24.04
> user 125.19
> sys 4.86
> 
> n=12 (matching logical core count)
> real 24.05
> user 125.55
> sys 4.67
> 
> maxPoolSize doesn't seem to make much of a difference with regard to real, user, or sys time.  To rule out a typo on my part I also ran with n=2, which promptly deadlocked my compiler.
> 
> But the difference between "no nosmt" and "nosmt" becomes even more pronounced when looking at the user and sys times, way beyond the real time's speedup of 1.2.
> 
> -- mva
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20231010/63cfb3f5/attachment.htm>