Strange interaction with hyperthreading on Intel hybrid CPU

[Michael van Acken]

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/7355e958/attachment.htm>