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

Hal,
> 1 июня 2016 г., в 14:22, Hal Finkel <hfinkel at anl.gov> написал(а):
> I agree that the 'openmp' runtime project logically fits within the
purview of a 'parallel' project. We may even want to move it there
eventually. We might also want it to remain separate while the project uses its
own coding conventions (which are different from LLVM's coding conventions
for historical reasons). We're not yet had that conversation, but it is a
good one to have.
Any reasons why we want to disrupt an established project and its users? Just
because we prefer "parallel" as a name for a new project and want to
validate this choice by moving an actual parallel runtime there?

Also, Chris' arguments on SE's lack of  users / standard body make a lot
of sense to me. I remember that CilkPlus was rejected for the same reasons. Why
SE (PPM, not the library) is different?

Yours,
Andrey
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160601/548ca1b2/attachment.html>

----- Original Message -----
> From: "andreybokhanko" <andreybokhanko at gmail.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "C Bergström" <cbergstrom at pathscale.com>,
"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>
> Sent: Wednesday, June 1, 2016 10:43:39 AM
> Subject: Re: [Openmp-dev] [llvm-dev] [cfe-dev] RFC: Proposing an LLVM
> subproject for parallelism runtime and support libraries
> Hal,
> 1 июня 2016 г., в 14:22, Hal Finkel < hfinkel at anl.gov >
написал(а):
> > I agree that the 'openmp' runtime project logically fits
within the
> > purview of a 'parallel' project. We may even want to move it
there
> > eventually. We might also want it to remain separate while the
> > project uses its own coding conventions (which are different from
> > LLVM's coding conventions for historical reasons). We're not
yet
> > had
> > that conversation, but it is a good one to have.
> 
> Any reasons why we want to disrupt an established project and its
> users? Just because we prefer "parallel" as a name for a new
project
> and want to validate this choice by moving an actual parallel
> runtime there?
I have no burning desire to shuffle around repositories for fun ;) -- I was
simply validating the point that the 'openmp' project could logically
fit within a larger project providing parallel runtimes. We should do this only
if there is a compelling reason. I see encouraging interaction between
developers working on similar things as a compelling reason. It is not clear
that applies in this case.
> Also, Chris' arguments on SE's lack of users / standard body make a
> lot of sense to me. I remember that CilkPlus was rejected for the
> same reasons. Why SE (PPM, not the library) is different?
We have some projects that conform to standard interfaces and some that
don't. There's no standard for much of compiler-rt's interface, for
example. The OpenMP runtime library itself does not conform to any particular
standardized interface (excepting OMP-T). We don't have CilkPlus in-tree in
Clang, and we don't have UPC either. We don't have a lot of potential
extensions in Clang, although we do certainly have some, and this is not the
right thread on which to discuss that issue, for SE or anything else.

Thanks again, 
Hal 
> Yours,
> Andrey
-- 

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/20160601/207fc15e/attachment.html>

ignorable tangent -

compiler-rt conforms to a defacto standard since it models after
libgcc interface, no? compiler-rt is also dead boring and stable (good
things) (well.. asan keeps them busy, but that doesn't impact the
interface..)

OMP runtime - huh? There's obviously an implementation wrapper around
pthreads for the compiler to chew on, but the exported/user facing
portions certainly do or should conform to the OMP standard.
Everything that is user facing is well defined and the whole process
from TR to finalization is established...


On Thu, Jun 2, 2016 at 5:07 AM, Hal Finkel <hfinkel at anl.gov>
wrote:
>
> ________________________________
>
> From: "andreybokhanko" <andreybokhanko at gmail.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "C Bergström" <cbergstrom at pathscale.com>,
"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>
> Sent: Wednesday, June 1, 2016 10:43:39 AM
> Subject: Re: [Openmp-dev] [llvm-dev] [cfe-dev] RFC: Proposing an LLVM
> subproject for parallelism runtime and support libraries
>
> Hal,
>
> 1 июня 2016 г., в 14:22, Hal Finkel <hfinkel at anl.gov> написал(а):
>
> I agree that the 'openmp' runtime project logically fits within the
purview
> of a 'parallel' project. We may even want to move it there
eventually. We
> might also want it to remain separate while the project uses its own coding
> conventions (which are different from LLVM's coding conventions for
> historical reasons). We're not yet had that conversation, but it is a
good
> one to have.
>
>
> Any reasons why we want to disrupt an established project and its users?
> Just because we prefer "parallel" as a name for a new project and
want to
> validate this choice by moving an actual parallel runtime there?
>
> I have no burning desire to shuffle around repositories for fun ;) -- I was
> simply validating the point that the 'openmp' project could
logically fit
> within a larger project providing parallel runtimes. We should do this only
> if there is a compelling reason. I see encouraging interaction between
> developers working on similar things as a compelling reason. It is not
clear
> that applies in this case.
>
>
> Also, Chris' arguments on SE's lack of  users / standard body make
a lot of
> sense to me. I remember that CilkPlus was rejected for the same reasons.
Why
> SE (PPM, not the library) is different?
>
> We have some projects that conform to standard interfaces and some that
> don't. There's no standard for much of compiler-rt's interface,
for example.
> The OpenMP runtime library itself does not conform to any particular
> standardized interface (excepting OMP-T). We don't have CilkPlus
in-tree in
> Clang, and we don't have UPC either. We don't have a lot of
potential
> extensions in Clang, although we do certainly have some, and this is not
the
> right thread on which to discuss that issue, for SE or anything else.
>
> Thanks again,
> Hal
>
>
> Yours,
> Andrey
>
>
>
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory

Just to address a specific point that Andrey raised here:

On Wed, Jun 1, 2016 at 8:43 AM andreybokhanko via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Also, Chris' arguments on SE's lack of  users / standard body make
a lot
> of sense to me. I remember that CilkPlus was rejected for the same reasons.
> Why SE (PPM, not the library) is different?
>
One important difference is that CilkPlus is essentially the same level of
complexity as CUDA+SE, and IMO the cost of supporting CUDA in Clang is huge
and dwarfs the other costs here[1]. But all of this is still an important
consideration.

CilkPlus was proposed quite a long time ago. At that point, things looked
very different: there had been relatively little active engagement in Clang
(which is what was primarily impacted by CilkPlus) by Intel. As a
consequence, the project was essentially looking at accepting a significant
contribution from a source with a limited history. Contributing significant
new functionality outside of any particular standard requires a really
strong level of trust and engagement with the community. Apple (obviously,
and somewhat trivially) built that, and there have been no problems with
Objective-C support in both Clang and LLVM. At Google, we've specifically
invested a lot of time and effort to build that level of relationship with
Clang and the project as a whole. And I'm happy to see Intel and others
investing in the same direction here; I think that's the only healthy way
to push for large changes like this.

Would CilkPlus contributions from Intel be accepted today? I honestly don't
know. Regardless, this will need to be a separate discussion.

Hope that helps explain my perspective here.
-Chandler

[1]: And don't get me wrong, I think it is worth the cost! =] I just
don't
want to misrepresent how large those costs are.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160602/0499f5ec/attachment.html>