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]

Re: My current idea for improving libgomp


On Tue, May 03, 2011 at 11:27:15AM +0900, Sho Nakatani wrote:
> In my opinion, even tied task needs user-level thread for scheduling.

I don't think so.  Of course you need some data structure for each task, but
having to allocate (even if from cache) a separate stack for each task is a
significant runtime cost, and if you ever want to deschedule a task and
change to another one, you either need to code your own swapcontext-ish
target specific stuff, or use setcontext/swapcontext with its overhead and
limitations and problems.  For tied tasks that are tied to a particular
thread anyway and can't be moved elsewhere I don't see what the additional
overhead would buy you, for untied tasks of course that is different.

> Also, it could be difficult to implement untied task without user-level thread.

Sure, but the overhead should be IMHO limited to untied tasks.

> So, implementing user-level thread for tied task will keep simplicity
> of task scheduler
> since libgomp will have untied task implementation in the future.

Will have it only if it is found to be actually beneficial.

> One global task queue which libgomp currently uses would be one of
> the biggest defeats. So I would first like to make new data structures
> including user-level threads with their private queues.

I don't see why you need user-level threads for having private queues,
you can very well have the private queues for each kernel thread instead.

	Jakub


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