Hi Matthew, Matthew Malcomson <[email protected]> writes:
> Nice to know others see the benefit! > > Having a common thread initialisation function sounds like a sensible idea. > > One complication would be that (once I've investigated the three > improvements I mentioned above) I expect some of the thread > initialization done in the generic code would not be things that the > targets use (e.g. the `num_teams` member). It seems to me that the particular example you mention is gated behind (defined (LIBGOMP_USE_PTHREADS)), so indeed that'd need to be behind such a preprocessor condition in the initialization function also. > I guess if that does turn out to be the case we could take a little > sub-optimality (in the parallel region so much less critical) rather > than making a generic function that is strongly tied to the current > implementation details of backends. I must admit that I didn't compare thoroughly the generic and platform-specific initialization code, so I am not sure how much of a difference there is, but, in the worst-case scenario, it's not unheard-of to place some steps behind #ifdef __AMDGCN__ and similar. With sufficient commentary, that should still be maintainable, mostly generic and optimal. If those conditions don't nest much (and I hope they wouldn't), I think it'd be alright to have a few such conditionals. Worst-case scenario, it can be split up more so that the backend-specific parts are implemented by the backend if it turns out to be a problem. -- Arsen Arsenović
signature.asc
Description: PGP signature
