3 ms·

Only for IO bound tasks, if you are doing a compute bound task that needs to saturate all cores, I am not sure what benefits virtual threads would bring.

cogman10 3y ago
Depends a lot on what you are doing and if you need preemption. There's not a huge penalty for using a virtual thread for compute (Other than impacting IO bound tasks).
PaulKeeble 3y ago
The trade off is going to remain the same for parallel algorithms, once saturated performance will gradually decline as swapping threads harms performance. Go for example exposes the CPU Core/thread count because unbounded performs worse even despite its apparently cheap virtual threads. I have tested this a number of times in Java and Go and the situation is similar you want to be using near the CPU count dependent on the algorithm and IO. It will be the same in Java with virtual thread, the cost of the threads will be lower but the optimal number likely wont change much.
- bcrosby95 3y ago
  In Java, unless they changed something in the past ~6 months, virtual threads will not "swap out" a CPU bound task, you have to have some blocking, otherwise it will keep on chugging. Depending upon your POV this may be a positive or negative. You can get around it by manually inserting some sleeps() - note that yield() won't work (which is kinda unfortunate).
  - deleted 3y ago
    [deleted]
  - peterashford 3y ago
    Does sleep(0) also work?
riku_iki 3y ago
> Only for IO bound tasks do you know any docs/examples how this can be integrated with current java io libraries?.
invalidname 3y ago
At the moment (as far as I know), only for NETWORKING bound tasks. Not general IO. Java at the moment doesn't support asynchronous file IO, this makes some sense since async-io on Linux is a bit of a mess still in terms of stability and security (but it's getting there so fingers crossed...). E.g. I'm building an app that does a lot of file IO and I won't be using virtual threads. They would provide nothing for this particular use case.

cogman10 3y ago

Depends a lot on what you are doing and if you need preemption. There's not a huge penalty for using a virtual thread for compute (Other than impacting IO bound tasks).

PaulKeeble 3y ago

The trade off is going to remain the same for parallel algorithms, once saturated performance will gradually decline as swapping threads harms performance. Go for example exposes the CPU Core/thread count because unbounded performs worse even despite its apparently cheap virtual threads. I have tested this a number of times in Java and Go and the situation is similar you want to be using near the CPU count dependent on the algorithm and IO. It will be the same in Java with virtual thread, the cost of the threads will be lower but the optimal number likely wont change much.

bcrosby95 3y ago
In Java, unless they changed something in the past ~6 months, virtual threads will not "swap out" a CPU bound task, you have to have some blocking, otherwise it will keep on chugging. Depending upon your POV this may be a positive or negative. You can get around it by manually inserting some sleeps() - note that yield() won't work (which is kinda unfortunate).
- deleted 3y ago
  [deleted]
- peterashford 3y ago
  Does sleep(0) also work?

riku_iki 3y ago

> Only for IO bound tasks do you know any docs/examples how this can be integrated with current java io libraries?.

invalidname 3y ago

At the moment (as far as I know), only for NETWORKING bound tasks. Not general IO. Java at the moment doesn't support asynchronous file IO, this makes some sense since async-io on Linux is a bit of a mess still in terms of stability and security (but it's getting there so fingers crossed...). E.g. I'm building an app that does a lot of file IO and I won't be using virtual threads. They would provide nothing for this particular use case.