Re: OpenMP for both clang and GCC, part II

On 2019/06/06 11:13, j@bitminer.ca wrote:
>
>
> On 2019-06-06 08:04, Stuart Henderson wrote:
> > On 2019/06/05 16:42, j@bitminer.ca wrote:
> > > Users will adopt flavors such as -withopenmp, or -noopenmp, as they
> > > become
> > > available.
> >
> > Flavours are often a bad idea, testing becomes more complicated,
> > especially for ports which are part of chains of dependencies. I think
> > they should probably be avoided for this.
>
> That would be good advice for future changes to existing ports.
>
> >
> > > Some issues and questions:
> > >
> > > - this will work for amd64, but will it work for arm64, sparc? Others?
> > > - should the flavors be -withopenmp or -noopenmp?
> > > - how to successfully detect 90% or more of ports with hidden OpenMP
> > > support?
> > > I will do this and am looking for advice on how best to approach it.
> > > Any pre-existing info would be very welcome.
> >
> > It would be helpful to see examples of what sort of improvement can be
> > expected on OpenBSD before deciding if it's worth the trouble to
> > integrate
> > into ports (which is an ongoing thing, not just one-off work).
>
>
> My own motivation is not ports but specifically clang/flang and gcc with
> OpenMP enabled. And maybe Octave. Initially I started to suggest a general
> implementation, thinking this wasn't too hard to also update a few
> packages....oops.
>
> Improvement would be measured how? By number of supporting ports, or
> number of frequently used numerically intensive ports (such as audio, video,
> or math tools)? I'd rather not judge and just try to give users options.

I'm thinking more at a very basic level for now: e.g. whether these
programs actually run any faster on OpenBSD when OpenMP is used.

> Forcing OpenMP disabled on most ports is obeying the principle of least
> surprise. Ongoing work would be selectively enabling it. And documenting
> how to control the number of threads.

Other ongoing work would be remembering that this is a thing and making
sure it's disabled where needed in new ports. (The worst case is if it
gets picked up and used at build time if the runtime is present and
produces a package that needs the runtime to work, but is otherwise
not very identifiable until someone tries to run the package on a
machine without the runtime.)

> The list of ports explicitly disabling openmp, and consumers of their shared
> libraries is a little surprising (emacs anyone?). Here is the list,
> approximately, to one level deep:

It's disabled in a few things where it was noticed (usually by reviewing
lists of options in configure --help or in build log), but I don't think
there has been much concerted effort to disable it throughout the tree.
bcallah made a start at this but IIRC only did a few categories.