<div dir="ltr">I think the biggest concern of completely moving to virtual threads is that they don't fairly share the CPU when there are more than cores virtual threads. This makes me hesitant to say they are the default.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 5, 2023 at 3:34 AM Ron Pressler <<a href="mailto:ron.pressler@oracle.com">ron.pressler@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The main thing I am trying to get across is not that virtual threads work best *only* when their number is high, but that the right way to adopt them is not to replace a platform thread with a virtual thread, but to represent some domain object (a request, a message etc.) with a virtual thread, and then, *as a result*, the number of virtual threads becomes a function of the load and will be high for systems under high load. This is particularly easy to do in very straightforward programs that don’t manually manage platform threads, and in these use-cases — where a virtual thread *doesn’t* replace a platform thread but some other object — we already match or exceed Go’s performance, especially when there’s some real work done. Adopting virtual threads in a useful manner in systems that depend on careful management of platform threads is harder.<br>
<br>
— Ron<br>
<br>
> On 5 Jan 2023, at 01:01, robert engels <<a href="mailto:rengels@ix.netcom.com" target="_blank">rengels@ix.netcom.com</a>> wrote:<br>
> <br>
> Understood. Thanks.<br>
> <br>
> For a large swath of “message systems†you are talking about hundreds of clients, not thousands, and certainly not millions. I am particularly referring to financial/trading systems.<br>
> <br>
> These usually use a fan-out structure so any given node only has < 100 clients and often far smaller than that. Latency is a huge concern however. This can be done with async IO and native threads but it doesn’t “feel like Java†- and is certainly harder to understand/maintain in my opinion.<br>
> <br>
> If Loom allowed Go like performance it would be a killer solution for these “router†type nodes.<br>
> <br>
> But please don’t take this as a strong criticism - in my testing Loom is within 10% of Go performance as it is today - which is a remarkable achievement especially given the backwards compatibility/programming model.<br>
<br>
</blockquote></div>