[llvm-dev] [cfe-dev] [Openmp-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries

Wed Jun 1 20:40:06 PDT 2016

On Wed, Jun 1, 2016 at 8:21 AM Mehdi Amini via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

>
> > On Jun 1, 2016, at 7:42 AM, C Bergström via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > On Wed, Jun 1, 2016 at 8:52 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> >> ----- Original Message -----
> >>> From: "C Bergström" <cbergstrom at pathscale.com>
> >>> To: "Hal Finkel" <hfinkel at anl.gov>
> >>> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "cfe-dev" <
> cfe-dev at lists.llvm.org>, "openmp-dev"
> >>> <openmp-dev at lists.llvm.org>, "Chandler Carruth" <chandlerc at gmail.com>,
> "Carlo Bertolli" <cbertol at us.ibm.com>,
> >>> "Andrey Bokhanko" <andreybokhanko at gmail.com>
> >>> Sent: Wednesday, June 1, 2016 6:46:57 AM
> >>> Subject: Re: [Openmp-dev] [llvm-dev] [cfe-dev] RFC: Proposing an LLVM
> subproject for parallelism runtime and support
> >>> libraries
> >>>
> >>> On Wed, Jun 1, 2016 at 7:22 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> >>>>
> >>>> ________________________________
> >>>>
> >>>> From: "C Bergström" <cbergstrom at pathscale.com>
> >>>> To: "Hal Finkel" <hfinkel at anl.gov>
> >>>> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "cfe-dev"
> >>>> <cfe-dev at lists.llvm.org>, "openmp-dev" <openmp-dev at lists.llvm.org>,
> >>>> "Chandler Carruth" <chandlerc at gmail.com>, "Carlo Bertolli"
> >>>> <cbertol at us.ibm.com>, "Andrey Bokhanko" <andreybokhanko at gmail.com>
> >>>> Sent: Wednesday, June 1, 2016 12:19:19 AM
> >>>> Subject: Re: [Openmp-dev] [llvm-dev] [cfe-dev] RFC: Proposing an
> >>>> LLVM
> >>>> subproject for parallelism runtime and support libraries
> >>>>
> >>>> The thread has lost focus and cherry picking replies..
> >>>>
> >>>> To restate things since maybe you missed my points
> >>>> ----
> >>>> 1) SE is a programming model and needs a home of it's own. Having a
> >>>> programming model with it's headers and all other stuff glued into
> >>>> a runtime
> >>>> project which intends to be universal and PM agnostic doesn't make
> >>>> sense.
> >>>>
> >>>> They'd start in separate subdirectories.
> >>>>
> >>>>
> >>>> 1.1) The more I look, the most it seems SE is just a step-child
> >>>> project and
> >>>> stuffing it in llvm while still not having any users or strong
> >>>> backing
> >>>> doesn't make sense. We have enough PM already and my gut feeling is
> >>>> this
> >>>> isn't going in a direction to bring in other stakeholders.
> >>>
> >>> Point by point because I don't agree with what you write below
> >>> entirely
> >>>
> >>>>
> >>>> I think this is the core of my reply. OpenMP has a strong user
> >>>> community,
> >>>
> >>> I'd agree here
> >>>
> >>>> but OpenMP 4 offloading is still young.
> >>>
> >>> ditto
> >>>
> >>>> OpenMP 4 offloading does not yet
> >>>> have a real user community
> >>>
> >>> agreement
> >>>
> >>>> yet because the first implementations just
> >>>> started shipping very recently.
> >>>
> >>> Partially strongly disagree - Maybe you meant on Power8?
> >>> Intel has had their support for OMP4 for quite some time. It may have
> >>> been buggy and focused on simd directive, but as best I can tell they
> >>> have worked quite hard to fix bugs and improve it.
> >>
> >> I meant across many platforms. Intel had preliminary support for OpenMP
> 4 offloading directives even before OpenMP 4 was standardized (in 2013).
> This did not include all of what ended up in the standard, and the
> offloading part of the standard needed to be fixed in a breaking way for
> OpenMP 4.1/4.5 regardless, so this is certainly the exception rather than
> the rule.
> >>
> >>>
> >>> (Shameless self promotion) We have had some degree of OMP4 offloading
> >>> for like 1.5 years now.. It's mostly targeting the GPU and x86, but
> >>> also more recently working on Power8/AArch64.
> >>>
> >>> I'm quite certain these companies all have varying degrees of OMP4
> >>> done: Cray, IBM, PGI
> >>
> >> Yes, many are working on implementations, and some have shipped.
> There's a list here: http://openmp.org/wp/openmp-compilers/ - no one here
> really lists any OpenMP 4 offloading implementations before 2015. PGI does
> not currently list OpenMP 4 at all (although they've certainly done a lot
> of work on OpenACC).
> >>
> >>>
> >>>> Furthermore, our implementation is certainly
> >>>> quite new, and OpenMP 4 offloading is really quite akin to SE in
> >>>> that
> >>>> regard.
> >>>
> >>> Strongly disagree - Intel has been working with the LLVM community on
> >>> the parsing/sema and other parts of OMP4 for like a year or more..
> >>> This has been a long and well vetted process backed back a well
> >>> defined standard.
> >>
> >> Yes, both Intel and IBM have contributed significantly to Clang in this
> regard.
> >>
> >>> Compared to SE which is just some thing that popped
> >>> up out of nowhere and
> >>
> >> It popped up in TensorFlow, which itself popped up out of nowhere, but
> is already a popular open-source project for machine learning.
> >>
> >>> has a couple people from Google throwing their
> >>> weight around.
> >>
> >> Google is a trusted member of the LLVM community and a major
> contributor. So I agree with you in the following sense: When Google
> promises to update the code to follow LLVM's coding conventions and to
> manage its future development in accordance with our community norms, I
> believe them. I think they've earned a place in the "trust but verify"
> category in this regard, and I think this is a positive thing.
> >>
> >
> > yes, but not every project that is started is finished and who would
> > be the maintainer if the person leaves Google?
>
> Like anything that bitrot and is no longer maintained in LLVM: it gets
> deleted (or the sources stay there but it is no longer updated/maintained).
> There are precedents: http://llvm.org/svn/llvm-project/

Strong +1.

This is no different than any of other significant contributions, by Google
or other significant contributor -- we're on the hook to maintain it. If we
stop doing that, it gets nuked.

>
>
>
> > I still don't see why
> > they can't fork it on github or create a project to let it bake and
> > get some users or traction.
>
> The intent may be that instead of creating a separate community of users,
> it'd create its community inside the llvm projects community. That looks
> like a nice "feature" long term.
>
> Cost/benefit: cost is not really existent, potential benefits are
> interesting.
>

Agreed. That is exactly why we were interested in contributing it to LLVM.
We think it makes both LLVM and SE stronger from a community perspective to
have the diversity here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160602/7221d6d6/attachment.html>