On Tue, Apr 5, 2011 at 4:37 PM, Jakub Jelinek <ja...@redhat.com> wrote: > 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.laysak...@gmail.com> wrote: >> > From: Jakub Jelinek <ja...@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.
Indeed, the Lazy Task Creation scheme is 20 years old, which does not mean it isn't good, but it's very likely that much more has been done in that area. >> 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. Yes, but I don't think Sho means to implement that for tied tasks. I agree that respecting the standard for tied tasks would preclude using this scheduling model. Antoniu
