Chandler Carruth via llvm-dev
2016-May-09 18:07 UTC
[llvm-dev] [cfe-dev] [Openmp-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries
On Mon, May 9, 2016 at 12:04 PM Andrey Bokhanko via cfe-dev < cfe-dev at lists.llvm.org> wrote:> Thanks Jason (and Chandler) to tell Chandler's opinion, though it still > doesn't answer my original question: > > > > Both SE and libomptarget are libraries that handle offloading, not > parallelism. I understand other libraries, to be added in the future, might > deal with parallelism, but maybe we need a separate project for them? > (Something Chris already hinted.) > > The example simply adds confusion > > > > One example he brought up was AVX 512. He thinks that code explicitly > targeting CPU parallelism should also be included in this project, even > though it doesn't fit in the category of "offloading". > > Do we want to add a vectorizer to this project as well? >I would not expect a vectorizer to really fit here, no. But I would like to have this be a viable home for support libraries used by vectorizers if that proves useful. I thought this was usefully captured by the '_rt' or '_libs' suffix. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160509/4f152675/attachment.html>
Andrey Bokhanko via llvm-dev
2016-May-10 15:32 UTC
[llvm-dev] [cfe-dev] [Openmp-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries
On Mon, May 9, 2016 at 9:07 PM, Chandler Carruth <chandlerc at gmail.com> wrote:> > I would not expect a vectorizer to really fit here, no. >I didn't actually suggested to include vectorizer (sorry if wasn't clear) -- my whole point that "parallel" is too broad and frankly confusing word. Yours, Andrey -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160510/0bacc190/attachment.html>
Carlo Bertolli via llvm-dev
2016-May-10 18:12 UTC
[llvm-dev] [Openmp-dev] [cfe-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries
Hi A comment on the naming, while re-reading this thread: it **may** be that "acceleration" is a better adjective for the project you have in mind, rather than "offloading" (not applicable to AVX and homogeneous clusters of Intel Xeon Phi) or "parallel" (everything is parallel at this point). I actually think that acceleration is too generic as a term, and misleading in some cases, but it may fit your needs here. Thanks -- Carlo From: Andrey Bokhanko via Openmp-dev <openmp-dev at lists.llvm.org> To: Chandler Carruth <chandlerc 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 Date: 05/10/2016 11:32 AM Subject: Re: [Openmp-dev] [cfe-dev] [llvm-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries Sent by: "Openmp-dev" <openmp-dev-bounces at lists.llvm.org> On Mon, May 9, 2016 at 9:07 PM, Chandler Carruth <chandlerc at gmail.com> wrote: I would not expect a vectorizer to really fit here, no. I didn't actually suggested to include vectorizer (sorry if wasn't clear) -- my whole point that "parallel" is too broad and frankly confusing word. Yours, Andrey_______________________________________________ Openmp-dev mailing list Openmp-dev at lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160510/55aea10d/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160510/55aea10d/attachment.gif>
Chandler Carruth via llvm-dev
2016-May-10 21:05 UTC
[llvm-dev] [Openmp-dev] [cfe-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries
I think both "accelerator" and "offload" have the same problem for me -- they really seem too narrow. There are a lot of use cases for runtime libraries that are targeted at the host CPU. Perhaps your host CPU has a nice SIMD unit or it has lots of cores. Essentially, I feel like at least some of these runtimes are fundamentally about exploiting parallelism, which is why I argue for that naming convention. A concrete example that none have really addressed: a serious use case I would like to see the project address is to have an LLVM hosted vectorized math library that we can teach the compiler to leverage when vectorizing code (and allow users to call directly). Another example use case that I don't think would be well addressed with "offload" naming: producing the core runtime support libraries used to implement the new C++ parallelism TS in libc++. Now, we could put these libraries into compiler-rt, but I really feel like they will have more in common with the things in this repository than compiler-rt. I would very much like us to go with a *broad* name that allows many use cases to work effectively in this project, rather than a narrow and specific name. The libraries themselves should have specific and clear names, but I don't really want to encourage a proliferation of top level projects by their charters being overly narrow. -Chandler On Tue, May 10, 2016 at 12:14 PM Carlo Bertolli <cbertol at us.ibm.com> wrote:> Hi > > A comment on the naming, while re-reading this thread: it **may** be that > "acceleration" is a better adjective for the project you have in mind, > rather than "offloading" (not applicable to AVX and homogeneous clusters of > Intel Xeon Phi) or "parallel" (everything is parallel at this point). > > I actually think that acceleration is too generic as a term, and > misleading in some cases, but it may fit your needs here. > > Thanks > > -- Carlo > > [image: Inactive hide details for Andrey Bokhanko via Openmp-dev > ---05/10/2016 11:32:45 AM---On Mon, May 9, 2016 at 9:07 PM, Chandler C]Andrey > Bokhanko via Openmp-dev ---05/10/2016 11:32:45 AM---On Mon, May 9, 2016 at > 9:07 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > > From: Andrey Bokhanko via Openmp-dev <openmp-dev at lists.llvm.org> > > > To: Chandler Carruth <chandlerc 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 > > Date: 05/10/2016 11:32 AM > > > Subject: Re: [Openmp-dev] [cfe-dev] [llvm-dev] RFC: Proposing an LLVM > subproject for parallelism runtime and support libraries > Sent by: "Openmp-dev" <openmp-dev-bounces at lists.llvm.org> > ------------------------------ > > > > On Mon, May 9, 2016 at 9:07 PM, Chandler Carruth <*chandlerc at gmail.com* > <chandlerc at gmail.com>> wrote: > > > I would not expect a vectorizer to really fit here, no. > > > I didn't actually suggested to include vectorizer (sorry if wasn't clear) > -- my whole point that "parallel" is too broad and frankly confusing word. > > Yours, > > Andrey_______________________________________________ > Openmp-dev mailing list > Openmp-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160510/ca36c53b/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160510/ca36c53b/attachment-0002.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160510/ca36c53b/attachment-0003.gif>
via llvm-dev
2016-May-11 01:10 UTC
[llvm-dev] [Openmp-dev] [cfe-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries
<html><head></head><body lang="en-US" style="background-color: rgb(255, 255, 255); line-height: initial;"> <div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">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.</div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">Accelerator lib... feels odd</div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">What about computation lib?</div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">ā€ˇSorry on phone and can't quote your text, but about math libraries and c++ standard..</div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">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. 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.. </div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">C++-standard... why would this live anywhere except libc++? Should filesystem be in compiler-rt instead?</div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">----</div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">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.</div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">You can call this a 'lib' but will it ever be a runtime? </div></body></html>