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

Tue May 31 20:21:43 PDT 2016

I think that we should settle on a name and move on with this. Furthermore, I think that something broad, like 'parallel', is a good term for this. 'compiler-rt' is also broad (there are lots of different runtime libraries in it). I think that we, the larger LLVM community, want the SE developers and the lib*offload developers to form a mutually-collaborating part of the LLVM community, and so putting those two libraries in the same LLVM project makes sense. This will make it easy for, and will encourage, developers of both libraries to pay attention to commits to both libraries. 

Given the nature of parallel-programming models, however, we don't want this to be too restricted in scope. Non-accelerator-based parallel programming runtimes can also potentially have a place here. 

Thanks again, 
Hal 

----- Original Message -----

> From: "via Openmp-dev" <openmp-dev at lists.llvm.org>
> To: "Chandler Carruth" <chandlerc at gmail.com>, "Carlo Bertolli"
> <cbertol at us.ibm.com>, "Andrey Bokhanko" <andreybokhanko at gmail.com>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "cfe-dev"
> <cfe-dev at lists.llvm.org>, openmp-dev at lists.llvm.org
> Sent: Wednesday, May 11, 2016 3:53:42 AM
> Subject: Re: [Openmp-dev] [llvm-dev] [cfe-dev] RFC: Proposing an LLVM
> subproject for parallelism runtime and support libraries

> Ok at the end of the day why are you

> #1 fighting about the name? The names proposed aren't misleading. If
> it all comes down to feelings we're at an en passe of 2 vs 1

> #2 why is having more projects with clear scopes ‎a bad thing?
> ------
> I can contribute at least 7 years of hands on accelerator library
> design experience across multiple accelerators and various
> programming models.. This of course doesn't make me "right" but I
> view things from a much larger picture than just SE.

> The build doesn't have to be complicated at all. It would be along
> the same lines as lldb or compiler-rt. This is an implementation
> detail and to me is a weak reason to not have focused projects. (yes
> I do love and advocate tightly coupled when it makes sense)

> Clear goals and mission means less confusion. It can always be
> expanded later. Right now we have 3.5 things which can more or less
> be contributed to the project.

> Intel offload library
> Your SE thing
> I can contribute an API for review which may help things work
> together in the future. (This is more long term)
> ‎3.5 - the ocl runtime author works for Google btw

> They will all start disconnected but long term could slowly start to
> work together..

> A programming model is not a small scoped project.. it's like saying
> ocl, omp and other stuff should all be grouped together. SE is a
> programming model and if it's successful would need the same level
> of support as say cuda.

> Personally, I think your idea is good but there's many questions and
> on its own SE hasn't reached a level of maturity both technically
> and user adoption to warrant extreme views.

> OpenMP F2F meetings have like 50 companies and organizations
> represented. OpenACC has maybe 15 and 3 implementors. SE has....

> Does Google have a products page talking about SE? Has there been any
> announcement of support? ‎Docs and examples... I have asked many
> legitimate questions and so far not received solid answers..

> In contrast.. look at how Apple handled the launch of SWIFT or go
> back 8 years and NVIDIA cuda.. or way back in1996 with SGI +
> OpenMP..

> ‎More below and sorry if quotes are messed up

> From: Chandler Carruth
> Sent: Wednesday, May 11, 2016 13:47
> To: cbergstrom at pathscale.com; Carlo Bertolli; Andrey Bokhanko
> Cc: llvm-dev; cfe-dev; openmp-dev at lists.llvm.org
> Subject: Re: [llvm-dev] [Openmp-dev] [cfe-dev] RFC: Proposing an LLVM
> subproject for parallelism runtime and support libraries

> On Tue, May 10, 2016 at 7:11 PM < cbergstrom at pathscale.com > wrote:

> > The words to describe what you're referring to are onload vs
> > offloading. It's a very frequent term in networking as well as
> > computation.
> 

> > Accelerator lib... feels odd
> 

> > What about computation lib?
> 
> I don't find that any more clear.

> > ‎Sorry on phone and can't quote your text, but about math libraries
> > and c++ standard..
> 

> > Math libs *really* need their own home, source repo and project
> > page.
> > Unix philosophy, do one thing and do it well.. I'm not a big fan of
> > bucket of soup project.
> 
> I agree with you about the overarching philosophy, but I don't think
> it applies well to subprojects of LLVM.

> We should have *libraries* that do one thing and do them well. These
> libraries can have their own webpage and information, no problem.
> But they're all part of LLVM, and I'd like to keep the
> infrastructure as simple as possible. I really strongly feel like we
> should have a common home for these things that provides an umbrella
> of infrastructure, and then dedicated and specific information for
> the particular components.
> >>>
> Simple infrastructure is possible with what I'm talking about. What
> you're saying is like clang+llvm+lldb should al be one repo, but the
> REALITY is they are 3 separate. Complete-rt has its own home.. it
> shares a mailing list because it's low volume..

> > At the target layer depending on it may be nice but not required.
> > This is a big and wholly complex problem on its own. Do you write
> > it
> > in CUDA, OCL, asm, C.. is it just to provide vector versions of
> > functions or what about transcendentals... what about cuFFTW
> > alternative. then we go into accuracy vs speed discussions..
> 
> A lot of this is implementation questions. I think the mechanism of
> implementation should be largely based on what Clang and LLVM
> support well as that's the specific audience. I don't have strong
> opinions past that.

> >>>>
> My view is something which plays nice at a slightly higher level..
> clang and llvm support is Tier 1 and others contributing patches to
> play nice with others is welcomed. Would you disagree with that?

> > C++-standard... why would this live anywhere except libc++? Should
> > filesystem be in compiler-rt instead?
> 
> I'm not talking about the actual implementation of the C++ standard
> library, but the underlying *infrastructure* that is used. That
> infrastructure should be shared for lots of parallel programming
> workflows, one of which might be libc++'s APIs and others might be
> any of the other programmer interfaces here.

> As a concrete example, you might want to use stream executor under
> the hood to implement some parts of the C++ standard library's
> parallel extensions.

> >>>>>
> I'm not opposed to it but...
> I'm doubtful that SE would be the best target for implementing this.
> I won't go into specifics for why right now.

> > ----
> 
> > To add more complexity to the conversation.. what about debugging
> > and
> > profiling api.. from a tools perspective it should likely be
> > exposed
> > from the runtime.
> 

> > You can call this a 'lib' but will it ever be a runtime?
> 
> If there are runtime library components to support profiling and
> debugging, they should go there if they are parallel specific. We
> certainly have generic profiling libraries in compiler-rt.

> I guess I'm not seeing the problem here. But I also suspect that we
> can cross this bridge when we get there. I'm currently not
> specifically interested in these pieces, I've mentioned the specific
> and concrete use cases I have in mind.

> >>>>
> My concrete vision is
> SE is a programming model and needs a dedicated home. It can start
> under liboffload but gradually needs to be refactored. ‎This is the
> same as OMP.

> #2 SE, OMP and others long term target liboffload which then handles
> the target specific stuff. Be that AVX512/vec onload/offload or
> GPU..

> Liboffload will have many backends (nvidia/intel/amd) and many
> consumers ‎(omp/se/etc)

> Are you strongly against this?

> _______________________________________________
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev

-- 

Hal Finkel 
Assistant Computational Scientist 
Leadership Computing Facility 
Argonne National Laboratory 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160531/3ce2bb88/attachment.html>