From: Jakub Jelinek <j...@sunsite.ms.mff.cuni.cz> Date: Mon, 4 Apr 2011 20:15:38 +0200
> 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 Thanks a lot for your work. I'll read through it to help understand the concept of current GOMP implementation. I posted a new email a few hours ago in which I wrote what is the concept of `Lazy Task Creation' is. Do you have any comment on that? My current concern is that in order to implement Lazy Task Creation, a task should pause and resume its execution. So it's neccessary to implement context switch, which `MassiveThreads' does. Is it OK to write small assembly codes for each CPU architecture in libgomp? (I guess it is theoretically possible if some changes are added in Makefile) -- Sho Nakatani
