How to effectively split jobs into groups for multiprocessing when the job sizes are unknown

Question

With K processor cores, how to optimally split N jobs into groups, with each group to be processed sequentially by one processor core, when the time to process each job is unknown ahead of time and there is overhead associated with processing each group of jobs?

It is possible to kill a job group before it completes, but then no useful processing progress will be extracted from that job group.

If I just make each group size 1, add them to a queue, and process K of them at once, then the overhead can dominate the total time. If I split them into K equal sized groups, then the overhead can still dominate the total time and I could get unlucky and have all the slowest jobs in one group further slowing things down.

Is this an example of a general well studied problem with an understood algorithm to optimally process?

---

For example, suppose I have 326400 jobs, 32 cores, and about 5 seconds overhead associated with processing a group.

• 3,200 big jobs take 2 minutes each to process if done in four separate groups
• 3,200 medium jobs take 1 minute each to process if done in four separate groups
• the remaining 320,000 small jobs take about 5.001 seconds each to process if done in 320,000 separate groups.
• for the 5.001 seconds for the small jobs, 1 millisecond is due to the processing and 5 seconds is due to the overhead of processing any group. if all the small jobs are done in one group, it takes 325 seconds to process total due to sharing the overhead (320,000 * 1 millisecond + 5 seconds = 325 seconds)

If I just made each group size 1, put the groups in a queue, and ran 32 at a time concurrently on 32 cores, and happened to pick the 3,200 biggest jobs from the queue first, then the 3,200 medium jobs from the queue, it would take 200 minutes for the big jobs to finish, 100 minutes for the medium jobs to finish, and 833.5 minutes for the small jobs to finish: 18 hours total.

Optimally I would process the biggest jobs first (1 job per group), then the medium jobs (1 job per group), then split the remaining small jobs into 32 groups for a total of about 5 hours total to finish.

---

I am hoping that there is some well studied algorithm that I am ignorant of that handles this situation well.

Answer 1

Yes, this is a well-studied problem. Job scheduling has been a large focus of active research in the high-performance computing community for decades.

Part of the answer to this problem will depend on how the jobs are distributed. If we can assume that whether a given job is short, medium, or long is independent random variable (e.g. its probability of being one type or another is random and doesn't depend on what type the previous job was,) then one of the best ways to solve this would probably be to simply run a queue on each core. Assign groups of jobs that will, on average, be sufficiently long to dominate the 5 second queuing time, but not so long that it will likely be running for hours on end. Once that queue is drained, assign it another group of jobs. This results in a load-balancing effect, as cores that finish their work sooner can go ahead and grab more work.

In your example, the probabilities for a particular job are as follows:
320,000 / 326,400 = .98 of 1 ms
3,200 / 326,400 = 0.01 of 60,000 ms
3,200 / 326,400 = 0.01 of 120,000 ms

This gives an expected duration for a given job of (0.98 * 1) + (0.01 * 60,000) + (0.01 * 120,000) = 601 ms

So, if, for example, you want to get the 5s overhead down to 5% of the expected time of a given job group, you'd need job groups of size (19 * 5000) / 601 = 158 jobs per group. When a core finished those jobs, then just give it that many more from the remaining pool of jobs. This would give you an expected job group runtime of 158 * 601 ms + 5000 ms = 100,000 ms

Where you could run into problems with the above method is if the previously-mentioned assumption of job length being evenly-distributed does not hold. If, for instance, all of your large jobs had a significant likelihood of being adjacent to each other, then you could end up assigning job groups whose length varies dramatically from the expected value. If this is a potential issue in your case, you could mitigate it somewhat by effectively using something like a round-robin algorithm for creating a group of jobs. For instance, rather than grabbing a bunch of adjacent jobs from the pool of remaining jobs when you're creating a job group for a core, you could grab every 32nd job, so that clusters of large jobs together would likely be split up between the different cores.