Virtual Threads performance

[Alan Bateman]

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 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.