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

Chandler,

Thank you for getting it up to ML top.

I believe we have to move broader than that you just mentioned. The natural
separation of the infrastructure into different parts can be across the
following lines:

- the parallel model of programming - these can be OpenMP, OpenACC,
CilkPlus, OpenCL, StreamExecutor, CUDA, C++ parallel extensions, etc.
- the offloading machinery to be used by any of those above and providing
unified interfaces across all targets to be supported
- the performance libraries collection that can be re-used in different
programming models and be targeting different host/targets planforms

I would like to touch the 2nd bullet, since I had most exerience with
it.There should be a single interface for all offloading players that are
willing to take part. Those are not limited to StreamExecutor and the
OpenMP already published in LLVM. There are number of solutions from Intel,
not saying of others, - it would be reasonable to become a platform for all
of them, and I got positive feedback on the idea within.
To name a few (don't take it as an ad):

 - Hetero Streams Library, https://01.org/hetero-streams-library
 - Beignet Project, https://01.org/beignet
 - Math Kernel Libraries, https://software.intel.com/en-us/intel-mkl
 - Intel Compiler, https://software.intel.com/en-us/intel-compilers

I believe we shouldn't make any difference between StreamExecutor and other
projects and to try to plug one into the other or vice versa. The better
would be to reuse the same ground level I/O machinery that will provide
efficiency to all of these and the newcomers. The machinery should have
some specific attributes, such as support of multitude of languages
currently employed by LLVM project and beyond. Also we have to take into
account different application of the compiler and infrastructure: there can
be server solutions where we are free to use full-featured C++ and there
can be embedded solutions, such as automotive, where customers are tend to
have as few runtime support as possible and like C the most.



Regards,
Sergos
Intel Compilers




On Sat, Apr 23, 2016 at 1:24 AM, Chandler Carruth via Openmp-dev <
openmp-dev at lists.llvm.org> wrote:
> On Fri, Apr 22, 2016 at 3:05 PM Mehdi Amini <mehdi.amini at
apple.com> wrote:
>
>>
>> > On Apr 22, 2016, at 3:01 PM, Chandler Carruth <chandlerc at
gmail.com>
>> wrote:
>> >
>> > I feel like this thread got a bit stalled. I'd like to pick it
up and
>> try to suggest a path forward.
>> >
>> > I don't hear any real objections to the overall idea of having
an LLVM
>> subproject for parallelism runtimes and support libraries. I think we
>> should get that created.
>>
>> I think it should be clarified if "parallelism runtimes and
support
>> libraries" are intended to expose user-level APIs or if these are
intended
>> to expose APIs for the compiler generated code (this may be part of
your
>> point about "writing up its charter, scope" but I also think
it shouldn't
>> be underestimated as a task so I called it out).
>>
>
> Absolutely. I think that needs to be clearly spelled out.
>
> Personally, I'd like to see the subproject open to *both*. Here are
some
> libraries I would love to see (but don't necessarily have concrete
plans
> around):
> - A nice vectorized math library
> - Linear algebra libraries like BLAS implementations or such
> - Highly tuned FFT or other domain specific libraries for GPUs.
> Essentially the same is the vectorized math libraries but for GPUs and
> slightly higher level.
> - Stream executor
> - Any generic components of the OpenMP libraries.
>
> Clearly each of these would need to be discussed on a case by case basis,
> but there seems to be a healthy mixture of both user-level APIs and
> compiler-level APIs. I would suggest criteria for being here along the
> lines of:
>
> - Includes compiler-targeted APIs (maybe in addition to user-level APIs,
> maybe even with overlap), or
> - Leverages compiler details for its implementation (for example, using
> vector extensions we know LLVM supports), or
> - Wants to use compiler-specific packaging techniques or other integration
> techniques (for example shipping as bitcode), or
> - Helps support compiler or programming language functionality
>
> The first three here seem clear cut to me. If any part of the library is
> intended to be callable by the compiler, its a good fit. SE has such
> interfaces. Vectorized math libraries do too, etc. If the implementation of
> th elibrary really wants to use compiler internals like our vector math
> extensions, again, I think it makes sense to keep it reasonably co-located
> with the compiler.
>
> The last seems a bit tricky, but I think its really important. Currently,
> CUDA provides a pretty big programming surface, and having a well tuned
> BLAS or FFT implementation for example that integrates with CUDA is pretty
> important. Similarly in the future, we expect C++ to get lots of parallel
> standard library interfaces, potentially even BLAS-looking ones and we
> might want a good parallel BLAS implementation or other very fundamental
> parallel library implementation to use when implementing it.
>
> But at the same time, I think its really important to have a clear place
> where any library here ties back into the compiler ecosystem and/or the
> programming language ecosystem that are the core of LLVM.
>
> Does this seem like its going in the right direction? (Jason can probably
> take on the non-trivial task of writing this up more formally and make sure
> it is clearly documented.)
>
>
>> Otherwise you plan sounds good to me.
>>
>> --
>> Mehdi
>>
>>
>>
>> >
>> > I don't actually see any real objections to StreamExecutor
being one of
>> the runtimes. There are some interesting questions however:
>> > - Is there common code in the OpenMP runtime that could be unified
with
>> this?
>> > - Could OpenMP end up using SE or some common shared library
between
>> them as a basis for offloading?
>> > - Would instead it make more sense to have the OpenMP offload
library
>> be a plugin for StreamExecutor?
>> >
>> > I don't know the answer to any of these really, but I also
don't think
>> that they should prevent us from making progress here. And I think if
>> anything, they'll become easier to answer if we do.
>> >
>> > So my suggestion would be:
>> > 1) Create the broader scoped LLVM subproject, including writing up
its
>> charter, scope, plans, etc.
>> >
>> > 2) Add stream executor to it
>> >
>> > 3) Initially, leave the OpenMP offloading stuff targeted at
OpenMP.
>> Then, as it evolves, consider moving it to be another runtime in the
broad
>> project if and when it makes sense.
>> >
>> > 4) As both OpenMP and SE evolve and are used some in the project,
>> evaluate whether there is a common core that makes sense to extract. If
so,
>> do it and rebase them appropriately.
>> >
>> >
>> > Does this make sense? Are there objections to moving forward here?
>>
>>
> _______________________________________________
> 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/20160425/0f5922f5/attachment.html>

On Mon, Apr 25, 2016 at 11:41 AM Sergey Ostanevich via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Chandler,
>
> Thank you for getting it up to ML top.
>
> I believe we have to move broader than that you just mentioned. The
> natural separation of the infrastructure into different parts can be across
> the following lines:
>
> - the parallel model of programming - these can be OpenMP, OpenACC,
> CilkPlus, OpenCL, StreamExecutor, CUDA, C++ parallel extensions, etc.
> - the offloading machinery to be used by any of those above and providing
> unified interfaces across all targets to be supported
> - the performance libraries collection that can be re-used in different
> programming models and be targeting different host/targets planforms
>
> I would like to touch the 2nd bullet, since I had most exerience with
> it.There should be a single interface for all offloading players that are
> willing to take part. Those are not limited to StreamExecutor and the
> OpenMP already published in LLVM. There are number of solutions from Intel,
> not saying of others, - it would be reasonable to become a platform for all
> of them, and I got positive feedback on the idea within.
> To name a few (don't take it as an ad):
>
>  - Hetero Streams Library, https://01.org/hetero-streams-library
>  - Beignet Project, https://01.org/beignet
>  - Math Kernel Libraries, https://software.intel.com/en-us/intel-mkl
>  - Intel Compiler, https://software.intel.com/en-us/intel-compilers
>
> I believe we shouldn't make any difference between StreamExecutor and
> other projects and to try to plug one into the other or vice versa. The
> better would be to reuse the same ground level I/O machinery that will
> provide efficiency to all of these and the newcomers. The machinery should
> have some specific attributes, such as support of multitude of languages
> currently employed by LLVM project and beyond. Also we have to take into
> account different application of the compiler and infrastructure: there can
> be server solutions where we are free to use full-featured C++ and there
> can be embedded solutions, such as automotive, where customers are tend to
> have as few runtime support as possible and like C the most.
>
I don't think anything I'm suggesting precludes these directions in the
future?

I just don't think it is reasonable to hold up starting to work on the
pieces that are ready now. OpenMP was ready some time ago and is making
fine progress. StreamExecutor is ready now, and I'd like to let it make
progress indepnedently. If and when unifying infrastructure and sharing it
across a diverse set of technologies like this is desirable, we can figure
out the design with concrete patches and steps to get there? It seems *way*
too early to try to design for all of the things you list considering that
many aren't even in LLVM currently.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160425/cbb59ac6/attachment.html>

I can't comment on all the things not directly used by llvm community,
but I feel pretty strongly that
1) An independent project like liboffload should exist ; which
2) Projects like SE and OpenMP should both be using it ; and further
3) SE shouldn't just do their own thing because they haven't figured
out how to make it work with other projects that already have some
overlapping behaviour
---------
If my points above are invalid - can someone clarify that SE and the
"stuff" in OpenMP-llvm doesn't actually overlap in functionality.




On Mon, Apr 25, 2016 at 11:46 PM, Chandler Carruth via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> On Mon, Apr 25, 2016 at 11:41 AM Sergey Ostanevich via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>>
>> Chandler,
>>
>> Thank you for getting it up to ML top.
>>
>> I believe we have to move broader than that you just mentioned. The
>> natural separation of the infrastructure into different parts can be
across
>> the following lines:
>>
>> - the parallel model of programming - these can be OpenMP, OpenACC,
>> CilkPlus, OpenCL, StreamExecutor, CUDA, C++ parallel extensions, etc.
>> - the offloading machinery to be used by any of those above and
providing
>> unified interfaces across all targets to be supported
>> - the performance libraries collection that can be re-used in different
>> programming models and be targeting different host/targets planforms
>>
>> I would like to touch the 2nd bullet, since I had most exerience with
>> it.There should be a single interface for all offloading players that
are
>> willing to take part. Those are not limited to StreamExecutor and the
OpenMP
>> already published in LLVM. There are number of solutions from Intel,
not
>> saying of others, - it would be reasonable to become a platform for all
of
>> them, and I got positive feedback on the idea within.
>> To name a few (don't take it as an ad):
>>
>>  - Hetero Streams Library, https://01.org/hetero-streams-library
>>  - Beignet Project, https://01.org/beignet
>>  - Math Kernel Libraries, https://software.intel.com/en-us/intel-mkl
>>  - Intel Compiler, https://software.intel.com/en-us/intel-compilers
>>
>> I believe we shouldn't make any difference between StreamExecutor
and
>> other projects and to try to plug one into the other or vice versa. The
>> better would be to reuse the same ground level I/O machinery that will
>> provide efficiency to all of these and the newcomers. The machinery
should
>> have some specific attributes, such as support of multitude of
languages
>> currently employed by LLVM project and beyond. Also we have to take
into
>> account different application of the compiler and infrastructure: there
can
>> be server solutions where we are free to use full-featured C++ and
there can
>> be embedded solutions, such as automotive, where customers are tend to
have
>> as few runtime support as possible and like C the most.
>
>
> I don't think anything I'm suggesting precludes these directions in
the
> future?
>
> I just don't think it is reasonable to hold up starting to work on the
> pieces that are ready now. OpenMP was ready some time ago and is making
fine
> progress. StreamExecutor is ready now, and I'd like to let it make
progress
> indepnedently. If and when unifying infrastructure and sharing it across a
> diverse set of technologies like this is desirable, we can figure out the
> design with concrete patches and steps to get there? It seems *way* too
> early to try to design for all of the things you list considering that many
> aren't even in LLVM currently.
>
> -Chandler
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>