This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Give me advice on GSoC OpenMP
On Tue, Apr 05, 2011 at 03:45:26PM +0200, Antoniu Pop wrote:
> On Tue, Apr 5, 2011 at 3:01 PM, Sho Nakatani <dev.laysakura@gmail.com> wrote:
> > From: Jakub Jelinek <jakub@redhat.com>
> > Date: Tue, 5 Apr 2011 08:33:23 +0200
> > Yes. Also, Lazy Task Creation has another good aspect.
> > Look at the pictures below. Both shows the call-tree of fibonacci(8).
> > One is compiled by gcc and the other is by icc.
> >
> > (GCC) https://github.com/laysakura/GCC-OpenMP-Speedup/raw/e5671e7f4175c3ac17c1543c93edf25dda2ae6ac/test/calltree/openmp-fibonacci-calltree-gcc.png
> > (ICC) https://github.com/laysakura/GCC-OpenMP-Speedup/raw/e5671e7f4175c3ac17c1543c93edf25dda2ae6ac/test/calltree/openmp-fibonacci-calltree-icc.png
As your testcase doesn't have untied keywords, I doubt ICC uses such scheduling
for it.
See also the paper Antoniu referenced, e.g. figure 7 in there.
If you want to do something about task scheduling as a GSoC project,
you are certainly welcome, but starting with the idea that
you want to implement Lazy Task Creation is probably not a good idea,
you want to read a bunch of papers, download Mercurium project
with its runtime OpenMP library, read it, see what they actually implement
and how and if they have multiple strategies still implemented in there,
see how they perform on the various OpenMP task testcases (we have some
in libgomp testsuite, but the authors of Mercurium also have some testcases
(called BOTS)), then try to implement some changes into libgomp/ and see how
it performs on various testcases with various parameters.
> You may also want to make sure the scheduling policy it enforces
> cannot interfere with OpenMP semantics. For example, how would the
> lazy task creation behave if a worker steals a bottom-of-the-stack
> task that has a taskwait and the tasks bound to this synchronization
> are left in the other worker's dequeue? There can be deadlock issues
> or just plain performance issues that can arise. I can't see any
> obvious issues, but it's worth thinking about.
Tied tasks have quite strict rules on what can be actually scheduled,
a new task to be scheduled must be descendant of all the tasks tied to current
thread that aren't waiting in a barrier.
Jakub