This is the mail archive of the gcc@gcc.gnu.org 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] |
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. Jakub
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] |