Virtual Threads performance

[Volker Simonis]

Alan Bateman <Alan.Bateman at oracle.com> schrieb am Mo., 3. Apr. 2023, 09:38:

> On 01/04/2023 21:00, Attila Kelemen wrote:
> > Hi,
> >
> > I bumped into this article (actually a while ago, but only now did I
> > start to experiment with the performance myself):
> >
> https://apiumhub.com/tech-blog-barcelona/project-loom-and-kotlin-some-experiments
> > comparing Kotlin coroutines vs. virtual threads.
> >
> > Though I don't think the article itself is a fair measure of Loom's
> > performance (given that most applications do not involve 100k threads
> > sleeping as their main purpose). Especially because when I did a
> > comparison with tasks actually doing some CPU work, then the results
> > were way in favor of Loom.
> >
> > Still, I find it strange that Kotlin coroutines can heavily outperform
> > Loom in the case when there is almost nothing but waiting (especially
> > in the case of timed waiting). Can anyone shed a light on why this can
> > happen? Is this because of a particular trade-off choice?
>
>  From a quick read, this seems to be more about Thread.sleep vs.
> coroutine delay.  Thread.sleep(0) reschedules the current thread whereas
> the documentation for delay(0) suggests it's a no-op.  For the >0 case,
> there is further work needed to improve virtual Thread.sleep. Right now
> it is based on a STPE and there can be contention on


What is "STPE"?

 its work queue. We
> have done some early experiments with hierarchical timing wheels that
> show promise. There have also been suggestions to use the OS timer
> facility. So improvements should come in time, it's just that other
> areas have been higher priority to date.
>
> Best to follow-up on loom-dev rather than here, esp. if you have your
> own benchmarks to discuss.
>
> -Alan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230403/38305f99/attachment.htm>