On Thu, Jan 24, 2013 at 10:46 PM, Michael Jones <
m...@google.com> wrote:
> Comment:
>
> I just finished a particular case of computation where the execution cost in
> terms of n = 2**n, with problems that could not be subdivided naturally. My
> default "biggest sub-problem first" task distributor, using GOMAXPROCS ==
> Num CPU, worked perfectly. The first go routine took time Total/2, and the
> other (Log2 N)-1 tasks took the same time so closely that after an hour or
> so of computation, the two halves of the computation finished within a few
> seconds of each other.
>
> I agree with Dmitry, but wanted to point out that when the tasks are not
> close to uniform size it can be VERY important to manage the order of task
> distribution. In the case above, any style of distribution to more than NCPU
> threads/tasks, or in any other order than launching the big one first,
> requires more total processing time.
Agree. That's what frequently missed by build tools like go, make, etc.
Sometimes it's possible to split tasks into subtasks further. This
becomes more important with increasing number of cores. Consider that