thr3ads.net - llvm dev - [llvm-dev] [Openmp-dev] [cfe-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries [Jun 2016]

If this information is useful, please help other people find it:
Share via:

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

head link

[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

head link

[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>

Maybe Matching Threads

Search for more possibly parallel threads

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

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

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

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

Maybe Matching Threads