llvm dev - Jun 2016 - [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>

----- Original Message -----
> From: "C Bergström" <cbergstrom at pathscale.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "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>, "Andrey Bokhanko"
<andreybokhanko at gmail.com>
> Sent: Wednesday, June 1, 2016 12:19:19 AM
> Subject: Re: [Openmp-dev] [llvm-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.
They'd start in separate subdirectories. 
> 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.
I think this is the core of my reply. OpenMP has a strong user community, but
OpenMP 4 offloading is still young. OpenMP 4 offloading does not yet have a real
user community yet because the first implementations just started shipping very
recently. Furthermore, our implementation is certainly quite new, and OpenMP 4
offloading is really quite akin to SE in that regard. I view them both as
experimental projects, and both have strong backing with significant investment,
so I expect both to mature over time. Our non-subtle strategic goal as a
community should be to encourage the various teams to take advantage of each
others expertise in the most practical way.
> 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.
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.

Thanks again, 
Hal 

-- 

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/b36e93a4/attachment.html>

On Wed, Jun 1, 2016 at 7:22 PM, Hal Finkel <hfinkel at anl.gov>
wrote:
>
> ________________________________
>
> From: "C Bergström" <cbergstrom at pathscale.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "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>, "Andrey Bokhanko"
<andreybokhanko at gmail.com>
> Sent: Wednesday, June 1, 2016 12:19:19 AM
> Subject: Re: [Openmp-dev] [llvm-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.
>
> They'd start in separate subdirectories.
>
>
> 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.
Point by point because I don't agree with what you write below entirely
>
> I think this is the core of my reply. OpenMP has a strong user community,
I'd agree here
> but OpenMP 4 offloading is still young.
ditto
> OpenMP 4 offloading does not yet
> have a real user community
agreement
> yet because the first implementations just
> started shipping very recently.
Partially strongly disagree - Maybe you meant on Power8?
Intel has had their support for OMP4 for quite some time. It may have
been buggy and focused on simd directive, but as best I can tell they
have worked quite hard to fix bugs and improve it.

(Shameless self promotion) We have had some degree of OMP4 offloading
for like 1.5 years now.. It's mostly targeting the GPU and x86, but
also more recently working on Power8/AArch64.

I'm quite certain these companies all have varying degrees of OMP4
done: Cray, IBM, PGI
> Furthermore, our implementation is certainly
> quite new, and OpenMP 4 offloading is really quite akin to SE in that
> regard.
Strongly disagree - Intel has been working with the LLVM community on
the parsing/sema and other parts of OMP4 for like a year or more..
This has been a long and well vetted process backed back a well
defined standard. Compared to SE which is just some thing that popped
up out of nowhere and has a couple people from Google throwing their
weight around.
> I view them both as experimental projects, and both have strong
> backing with significant investment, so I expect both to mature over time.
I'd agree both are experimental and probably need some work. I'd
strongly disagree the amount of investment of both projects is equal.
Again - OMP4 may have zero real world users, but there's a lot of
stubborn people trying to make it work. Compared to SE which the
people involved have yet to even answer basic things - like what's the
future of SE and how to contribute to it.
> Our non-subtle strategic goal as a community should be to encourage the
> various teams to take advantage of each others expertise in the most
> practical way.
I think we need to pushback against more programming models, but I
agree we should encourage lots of great patches around things like the
pass manager.

IMHO it's more productive to spend time trying to improve the
programming models and standards we have than experimental fun ideas.
---------
Can you point me at something concrete which SE would allow you to do
which an existing model can't?

I'll shutup and apologize if real side by side comparisons for the
beauty of SE come out.

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>