This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Give me advice on GSoC OpenMP

On Sun, Apr 03, 2011 at 08:10:25PM +0200, Jakub Jelinek wrote:
> On Sun, Apr 03, 2011 at 07:27:12PM +0900, Sho Nakatani wrote:
> > Then, I'll compare the trees created by gcc and icc, and point out
> > that the implementation of OpenMP Task uses Lazy Task Creation while
> > gcc does not.
> Depends on what you mean by lazy task creation, gcc schedules
> tasks lazily if they aren't if (0), some data structure if created
> for them when encountering #pragma omp task directive, but I guess
> any implementation will do something like that.
> What your testcase shows is not whether tasks are created lazily or not, but
> how good/poor #pragma omp taskwait implementation is.  And, for your testcase
> libgomp/task.c (GOMP_taskwait) definitely could be improved.  Currently it only
> tries to schedule in children that will be awaited by the current tasks and if
> there are no such children, goes to sleep, waiting for them to complete.
> Scheduling in random unrelated tasks is problematic, because the unrelated
> task might take too long to complete and delay the taskwait for way too long
> (note, gcc doesn't have untied tasks, all tasks are tied once they are scheduled
> onto some particular tasks - setcontext/swapcontext is quite fragile thing to do).
> But it is true it could very well schedule tasks that are taskwaited by tasks
> taskwaited by current task, and transitively further.  Plus, be able to temporarily
> awake such a sleeping thread if there are tasks it can transitively taskwait
> for, as if those don't complete, the current taskwait won't return.

Just FYI, I've tried to implement something like that as a quick hack,
but it unfortunately slowed things down, at least on the attached fib testcase
with arguments 40 25.  Guess partly the problem is that after a task waiting
in taskwait_sem is awaken it now needs to take task_lock lock to unqueue itself
from the new in_taskwait_list, and partly because the search for grand-grand children
etc. is more expensive, the FIFO isn't a good data structure for that.


Attachment: P3
Description: Text document

Attachment: fib.c
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]