Re: Implementing an algorithm in place of gomp 'auto'
> > The clang implementation seem have work stealing. > clang doesn't have its own runtime library, you mean the Intel OpenMP > library, right? I guess so. > > Also, out of curiosity, is there any plan to add work stealing (affinity > > schedules) to gomp? > It is on the wish list, but I'm afraid I won't have cycles for it in the > next year or two at least (once GCC 9 is released, I need to work on the > remaining OpenMP 5.0 features). Of course if somebody implements it and > submits > and it is of reasonable quality/performance, it will be accepted. Implementing work stealing (WS) also sounds interesting to me. Do you have any plan of how it should look like? For static scheduling, I don't quite see how WS could be implemented since the control doesn't enter the OMP runtime. Lastly, do you think the subjects we are discussing (Additional scheduling algorithms, doing something about auto, WS etc..) could make the cut for a GSoC 2019 project? Ray Kim -Original Message- From: "Jakub Jelinek" To: "김규래"; Cc: "gcc Mailing List"; Sent: 2019-03-02 (토) 02:46:14 (GMT+09:00) Subject: Re: Implementing an algorithm in place of gomp 'auto' On Sat, Mar 02, 2019 at 02:40:35AM +0900, 김규래 wrote: > 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? Yes. > Last time I looked, it seemed that adding a new scheduling keyword would > require quite some work. Not that much. > Also, out of curiosity, is there any plan to add work stealing (affinity > schedules) to gomp? It is on the wish list, but I'm afraid I won't have cycles for it in the next year or two at least (once GCC 9 is released, I need to work on the remaining OpenMP 5.0 features). Of course if somebody implements it and submits and it is of reasonable quality/performance, it will be accepted. > The clang implementation seem have work stealing. clang doesn't have its own runtime library, you mean the Intel OpenMP library, right? Jakub
Re: Implementing an algorithm in place of gomp 'auto'
On Sat, Mar 02, 2019 at 10:05:25PM +0900, 김규래 wrote: > > It is on the wish list, but I'm afraid I won't have cycles for it in the > > next year or two at least (once GCC 9 is released, I need to work on the > > remaining OpenMP 5.0 features). Of course if somebody implements it and > > submits > > and it is of reasonable quality/performance, it will be accepted. > > Implementing work stealing (WS) also sounds interesting to me. If you mean work stealing for worksharing loop scheduling, then it would need to be yet another non-standard schedule, the current schedules (except for auto or no schedule clause) don't allow it. If you mean work stealing for task scheduling, then that is more important. > Do you have any plan of how it should look like? > For static scheduling, I don't quite see how WS could be implemented since > the control doesn't enter the OMP runtime. Sure, explicit schedule(static, N) or schedule(static) is quite well defined and shouldn't go into the OMP runtime. I was talking about no schedule clause at all, then the spec says it is implementation defined what scheduling is used. > Lastly, do you think the subjects we are discussing (Additional scheduling > algorithms, doing something about auto, WS etc..) > could make the cut for a GSoC 2019 project? I think so. If you'd be interested in task scheduling, even better, but if not, I think enough work can be done on worksharing loop scheduling. Jakub
Re: Implementing an algorithm in place of gomp 'auto'
> > > It is on the wish list, but I'm afraid I won't have cycles for it in the > > > next year or two at least (once GCC 9 is released, I need to work on the > > > remaining OpenMP 5.0 features). Of course if somebody implements it and > > > submits > > > and it is of reasonable quality/performance, it will be accepted. > > > > Implementing work stealing (WS) also sounds interesting to me. > If you mean work stealing for worksharing loop scheduling, then it would > need to be yet another non-standard schedule, the current schedules (except > for auto or no schedule clause) don't allow it. > If you mean work stealing for task scheduling, then that is more important. > > Lastly, do you think the subjects we are discussing (Additional scheduling > > algorithms, doing something about auto, WS etc..) > > could make the cut for a GSoC 2019 project? > I think so. If you'd be interested in task scheduling, even better, but if > not, I think enough work can be done on worksharing loop scheduling. Great. I think task scheduling is indeed more important. I'll first take a look at the task system of gomp since I mostly worked on worksharing loop parallel stuff and write a GSoC proposal when ready. It will probably be about 1) implementing basic work stealing and then 2) maybe some locality-aware stuff. Is there a standard benchmark used by gomp for task parallelism? Ray Kim
