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: GSoC openMP task scheduling Advice


Hi All,

I applied gsoc for openMP taks scheduling and my advice may cover
taskyield facility. Currently i have some idea for taskyield. i think
i can add something. Therefore i wonder GCC mentor related about
openMP was announced? or should i wait until "student acceptance"?

Regards,
Güray Özen
Polytechnic University of Catalonia



2013/5/5 guray.ozen <guray.ozen@gmail.com>:
> Dear Tobias,
>
> Thank for your interest.
>
> Yes actually my Master program managed by BSC. So generally my professors
> work from BSC or Intel. I know BSC has a nanos group and the group works
> generally task scheduling. But i don't know any people from this group. If i
> get openmp task project, I'll meet them and i can request help. maybe they
> have good trick to implement my advice. Or they may improve my advice.
>
> Finally I applied gsoc. I hope I'll be accepted :) my advice can cover
> openmp3.1 taskyield facility beside task scheduling optimization. Of course
> task scheduling contains task stealing. Is like to much i can work on gcc
> for openmp.
>
> Regards,
>
> On May 3, 2013 1:08 AM, "Tobias Burnus" <burnus@net-b.de> wrote:
>>
>> Dear Güray,
>>
>> seemingly, Jakub is currently rather busy - let me try to answer the
>> questions, given that the GSoC dead line is tomorrow.
>>
>>> I'm MSc High-Performance Computing student at Polytechnic University
>>> of Catalonia(BarcelonaTech).
>>
>>
>> For curiosity, do you have something to do with the BSC? Or some other
>> on-site person, who is knowledgeable in OpenMP scheduling.
>>
>>
>> (I know that it is a separate entity, but it could be that you have still
>> some relation with them - or one of your professors.)
>>
>>> However i am not sure for this topics. Should i develop a new
>>> task-scheduler? otherwise should I optimize existing scheduler?
>>
>>
>> I think it would be useful to try a different talk scheduler, especially
>> with regards to task stealing. See http://www.cs.unc.edu/~olivier/ross11.pdf
>> for a comparison.
>>
>> Something similar like the task scheduling of OpenUH's DEQUEUE PER_THREAD1
>> with a doubly linked chain would be useful to try. (That's alledgedly
>> similar to the extension to the Qthreads multithreading library using the
>> ROSE compiler, used in Olivier's paper.)
>>
>> I think having some implementation of that scheduling and comparing it
>> with the current one would be useful - then one can decide whether the new
>> one is better or the current one or whether both should be available for the
>> user to switch between the two.
>>
>> In any case, it is useful to study the literature about the details - but
>> then get quickly starting with the implementation to make it possible to
>> really play with the scheduler in GCC.
>>
>>
>> Am 01.05.2013 18:50, schrieb guray.ozen:
>>>
>>> My advice i want to change or add task scheduler algorithm. The first
>>> thing I really want to add work-stealing mechanism. In this way i can
>>> decrease task waiting time and i can provide load-balancing.
>>
>>
>> Yes, that's in line with the idea above. I think one has to look at the
>> literature at the algorithm - and then try to get it implemented.
>>
>> Regarding the GSoC application, it would be good to give some success
>> criteria and time line - that helps later when implementing and also with
>> the application.
>>
>> For some ideas how to write the application, see:
>> http://drupal.org/node/59037, http://drupal.org/files/application.pdf,
>> http://of-code.blogspot.de/2007/08/soc-experience-introduction.html
>>
>> It is not required to be extremely long, but it should cover what exactly
>> you intent to do and how long the single steps will (roughly) take.
>>
>> Tobias


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