[PATCH] D36607: [Support/Parallel] - Do not spawn thread for single/last task.

[George Rimar via Phabricator via llvm-commits]

grimar added a comment.

In https://reviews.llvm.org/D36607#843193, @davide wrote:

> In https://reviews.llvm.org/D36607#843179, @grimar wrote:
>
> > In https://reviews.llvm.org/D36607#843164, @davide wrote:
> >
> > > Adaptive mutexes (e.g. for pthread_*) work using this principle. The kernel maintains a shared page and threads contending on the lock spin until the lock owner isn't descheduled.
> > >  This works because in general the cost of a context switch overcomes that of wasting few cycles spinning (under the assumption the CS is small).
> > >  An approximation of this scheme would be that of spinning for a certain number of cycles decreasing a variable each time (and going to sleep when the variable reaches zero).
> > >  This is, FWIW, what FreeBSD pthread mutexes do.
> > >  A different (and possibly more effective) proposal for `Parallel` would be that of exploring work-stealing algorithms for queueing.
> >
> >
> > Interesting.
> >  And what this patch do is orthogonal thing, since helps to avoid all threading/syncing overhead at all for free in some cases.
>
>
> This is not true in general. Imagine that the `Fn(J)` callback takes a considerable amount of time, much larger than the synchronization overhead, then your sequential version will take much more time than the parallel version (unless I'm missing some detail).


My version just executes the last task on the main thread (or single one if there is only one task). 
Original code would execute it in parallel single thread, and main thread would wait until it complete anyways (TaskGroup descructor calls sync()). 
So I believe there is no difference in execution time.


https://reviews.llvm.org/D36607