Is scheduling breath first or depth first in relation to concurrentTasksPerWorker? about piscina HOT 11 CLOSED

It’s going to pick the Worker that has the least amount of tasks currently being processed, i.e. yes, it picks “breadth first”. In your example, task 3 may end up being picked up by either worker, depending on which Worker finishes its task first.

from piscina.

Since Worker pools aren’t graphs: What would breadth-first or depth-first even mean here?

from piscina.

As I understand concurrentTasksPerWorker is how many tasks a worker can run concurrently.

So if I have concurrentTasksPerWorker = 2 and maxThreads = 2. How will the tasks be scheduled?

Let's say I have 3 tasks.

Breadth first:

Worker1: task 1
Worker2: task 2 (reached maxThreads start over)
Worker1: task 3

Depth first:

Worker1: task 1
Worker1: task 2 (reached concurrentTasksPerWorker switch to next worker)
Worker2: task 3

from piscina.

It likely would be a good idea to document that :-)

from piscina.

Would be nice to be able to implement a custom scheduler, i.e. I might want to consider cpu utilization instead of queue size. Or maybe even want to have it depth first if I have a IO mixed workload.

from piscina.

if I have a IO mixed workload.

I mean, in that case, don’t use Workers.

from piscina.

I mean, in that case, don’t use Workers.

There is a lot of computation mixed with IO. I could do the IO in master and then transfer to worker but that just adds lots of complexity.

from piscina.

I mean, in that case, don’t use Workers.

There is a lot of computation mixed with IO. I could do the IO in master and then transfer to worker but that just adds lots of complexity.

That’s generally the idea behind this library, though. From what it sounds like, piscina might not be the right fit for you, if you do I/O in the Worker pool anyway.

from piscina.

piscina might not be the right fit for you

It fits just fine even if not perfect. I'm moving low priority work with lot's cpu utilization off my main thread with almost no added complexity. Just could be even better with more fine grained scheduling.

from piscina.

I'm not convinced that changing the scheduling model would yield any significant benefit, regardless of the workload type.

@ronag, do you see a possible performance benefit?

from piscina.

Maybe. But it's a bit unclear to me as well. I think we can keep things simple as is.

from piscina.