via llvm-dev
2016-May-11 08:53 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);">Ok at the end of the day why are you </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);">#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 </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);">#2 why is having more projects with clear scopes a bad thing?</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);">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.</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);">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)</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);">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.</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);">Intel offload library </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);">Your SE thing</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);">I can contribute an API for review which may help things work together in the future. (This is more long term) </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);">3.5 - the ocl runtime author works for Google btw</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);">They will all start disconnected but long term could slowly start to work together..</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);">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.</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);">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.</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);">OpenMP F2F meetings have like 50 companies and organizations represented. OpenACC has maybe 15 and 3 implementors. SE has.... </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);">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..</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);"><span style="font-size: initial; text-align: initial; line-height: initial;"><br></span></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);"><span style="font-size: initial; text-align: initial; line-height: initial;">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.. </span></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);">More below and sorry if quotes are messed up</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 style="display:initial"></div> <div style="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> <table width="100%" style="background-color:white;border-spacing:0px;"> <tbody><tr><td colspan="2" style="font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);"> <div style="border-style: solid none none; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;"> <div><b>From: </b>Chandler Carruth</div><div><b>Sent: </b>Wednesday, May 11, 2016 13:47</div><div><b>To: </b>cbergstrom@pathscale.com; Carlo Bertolli; Andrey Bokhanko</div><div><b>Cc: </b>llvm-dev; cfe-dev; openmp-dev@lists.llvm.org</div><div><b>Subject: </b>Re: [llvm-dev] [Openmp-dev] [cfe-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries</div></div></td></tr></tbody></table><div style="border-style: solid none none; border-top-color: rgb(186, 188, 209); border-top-width: 1pt; font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);"></div><br><div id="_originalContent" style=""><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, May 10, 2016 at 7:11 PM <<a href="mailto:cbergstrom@pathscale.com">cbergstrom@pathscale.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div 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></blockquote><div><br></div><div>I don't find that any more clear.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div 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)"><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.</div></div></blockquote><div><br></div><div>I agree with you about the overarching philosophy, but I don't think it applies well to subprojects of LLVM.</div><div><br></div><div>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.</div><div>>>></div><div>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..</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div 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)"> 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></blockquote><div><br></div><div>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.</div><div><br></div><div>>>>></div><div>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? </div><div><span style="line-height: initial;"><br></span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div 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)"><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></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><div>>>>>></div><div>I'm not opposed to it but...</div><div>I'm doubtful that SE would be the best target for implementing this. I won't go into specifics for why right now.</div><div><span style="line-height: initial;"><br></span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div 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)">----</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></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><span style="line-height: initial;">>>>></span></div><div><span style="line-height: initial;">My concrete vision is </span></div><div><span style="line-height: initial;">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.</span></div><div><span style="line-height: initial;"><br></span></div><div><span style="line-height: initial;">#2 SE, OMP and others long term target liboffload which then handles the target specific stuff. Be that AVX512/vec onload/offload or GPU..</span></div><div><span style="line-height: initial;"><br></span></div><div><span style="line-height: initial;">Liboffload will have many backends (nvidia/intel/amd) and many consumers (omp/se/etc)</span></div><div><span style="line-height: initial;"><br></span></div><div><span style="line-height: initial;">Are you strongly against this?</span></div><div><span style="line-height: initial;"><br></span></div><div><span style="line-height: initial;"><br></span></div><div><span style="line-height: initial;"><br></span></div></div></div><!--end of _originalContent --></div></body></html>
Hal Finkel via llvm-dev
2016-Jun-01 03:21 UTC
[llvm-dev] [Openmp-dev] [cfe-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries
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>
C Bergström via llvm-dev
2016-Jun-01 05:19 UTC
[llvm-dev] [Openmp-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. 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. 2) Parallel name sucks -1, too generic. imho project is more focused on offloading. We're not proposing the whole OpenMP runtime be merged here, but just the offloading part. Yes onloading will be included, but just the generic pieces. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160601/659e2563/attachment.html>
Possibly Parallel Threads
- [Openmp-dev] [cfe-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries
- [Openmp-dev] [cfe-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries
- [Openmp-dev] [cfe-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries
- [Openmp-dev] [cfe-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries
- [Openmp-dev] [cfe-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries