[External] : Re: Performance of pooling virtual threads vs. semaphores

[robert engels]

(Sorry, I know you just said “never use pool vt”… I meant it as a possibility in the face of new information, review, etc.).

> On Jun 5, 2024, at 8:27 PM, robert engels <rengels at ix.netcom.com> wrote:
> 
> Totally agree, but then I guess I don’t understand how “most submissions would be internal” holds. It seems there is an unstated expectation of the workloads used with virtual threads. It may be as simple as “use virtual threads when your workload looks this…”, “use pooled virtual threads when your workload looks like this…”, use “platform threads…”, etc.
> 
> I’m not saying anything needs to change, only that I think more clarity on these dynamics would help. And it is totally ok to say “for now…”.
> 
> Just my two cents.
> 
> 
>> On Jun 5, 2024, at 8:02 PM, Ron Pressler <ron.pressler at oracle.com> wrote:
>> 
>> 
>> 
>>> On 5 Jun 2024, at 22:58, robert engels <rengels at ix.netcom.com> wrote:
>>> 
>>> Hi Ron,
>>> 
>>> When you say "most submissions would be internal” is that under the assumption that in a thread per request model, the number of times the thread “blocks” would X for each request, meaning there would be N*X internal submissions for every N requests.
>>> 
>>> So if you had requests with a low number of blocks (context switches) then pooling the virtual threads would be better?
>>> 
>> 
>> No, virtual threads should never be pooled.
>> 
>> I can’t even know if external submissions play a role in the behaviour difference here, only this microbenchmark doesn’t resemble the intended realistic workload in that regard and it’s very hard to extrapolate from microbenchmarks.
>> 
>> If this aspect does cause a significant difference, then if that patterns happens to be common in realistic workloads, then we’ll have a reason to properly profile them and then change the scheduling algorithm accordingly. In any event, you should never write less idiomatic code to exploit an accidental and undocumented — and therefore quite possibly a temporary one. 
>> 
>> Idiomatic code is always more likely to be the target of future improvement, and unidiomatic code is more likely to suffer because it’s less likely to be profiled and optimised. From time to time we see some strange code that’s causing an issue and we ask the authors why they wrote code like that and they say that it’s to enjoy some benefit due to some undocumented implementation detail of the runtime’s, only that implementation changed three years ago...
>> 
>> — Ron
>> 
>> 
>> 
>