Re: Implementing an algorithm in place of gomp 'auto'

[김규래<msca8h at naver dot com>]

Nice to meet you Jacob.
 
> Another option is to add further schedules as extensions (say starting with
> gnu_ prefix or similar). 
 
In this case, I believe that modifying the frontend would be necessary?
Last time I looked, it seemed that adding a new scheduling keyword would require quite some work.
Also, out of curiosity, is there any plan to add work stealing (affinity schedules) to gomp?
The clang implementation seem have work stealing.
 
Ray Kim 
 
-----Original Message-----
From: "Jakub Jelinek"<jakub@redhat.com>
To: "김규래"<msca8h@naver.com>;
Cc: "gcc Mailing List"<gcc@gcc.gnu.org>;
Sent: 2019-03-02 (토) 02:32:29 (GMT+09:00)
Subject: Re: Implementing an algorithm in place of gomp 'auto'
 
On Fri, Mar 01, 2019 at 11:40:50PM +0900, 김규래 wrote:
> Hello everyone,
> I'm an EE student at Sogang University Korea.
> I have recently submitted a paper on parallel loop scheduling algorithm and had to modify libgomp a bit in the process.
> It is known that the...
>  
>  
>
> /* For now map to schedule(static), later on we could play with feedback driven choice. */
>
>
> ... comment has been in place for quite a while.
> I'm curious if experimentally implementing a non-OMP-standard algorithm for the auto policy would be interesting.
> Specifically, one of the Tapering Self-Scheduling, Bold Self-Scheduling, Factoring Self-Scheduling [1] algorithms.
> If that is the case, I would like to propose this project for GSoC 2019.

For auto yes, if it makes good results, though it would be nice to use some
smarts on the compiler side to decide if the loop is a good candidate for
such scheduling, static scheduling has the major advantage that it doesn't
need to enter the runtime library (except for querying number of threads and
thread number, but those can be cached from earlier and barrier at the end
if not nowait) and for many common loops where the work in each iteration is
really constant it also gives best results.

Especially for the case when schedule clause is not present at all, we'd
need to do a very good job at the compiler side to use some dynamic
algorithm when it is likely it will be beneficial.  Unfortunately at least
right now the lowering to either static scheduling or a library call is done
quite early, before inlining etc., and for best decisions we'd need to
either defer it to far later, or be able to convert a library call back to
static scheduling.

Another option is to add further schedules as extensions (say starting with
gnu_ prefix or similar).

Jakub