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

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
>

On Mon, Apr 25, 2016 at 12:14 PM C Bergström <cbergstrom at pathscale.com>
wrote:
> 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.
>
It isn't that any of these points are invalid, it's just that I
don't think
we know how or if these projects have a useful overlap to extract and keep
separate. That was the whole point of my email suggesting that we shouldn't
try to force some hypothetical refactoring that we don't even know will
work to happen. Several serious technical challenges have been raised with
doing this refactoring, so its not just avoiding it for the sake of
avoiding it.

Even if/when these issues are sorted out and it is feasible to refactor
things to have a common layer, it still isn't clear whether the overlap is
actually that useful. I think we're over analyzing and designing this when
we don't even have the code in place to see if there is an interesting
problem to solve here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160425/d7d11e62/attachment.html>

Speaking from 1st hand experience -

The off-the-cuff high level benefits
1) Better interopt of different programming models - For example what
if someone wants to mix SE+OMP(4). Having the same runtime on the
backend should make this a lot easier. (Maybe this particular example
may never happen, but I hope you get what I'm talking about)
2) Less duplication of effort for common things.
3) Easier time for new programming models

By ignoring the current technical issues it's just playing
kick-the-can for someone less intimate with SE or OMP.

I hate to pushback on SE for this general requirement, but it seems
like the right time to do it. If not now - At which point does it make
sense?
-------------
My real honest motivation here is for Google and Intel to join
together on this. I believe SE will be much better long term if major
stakeholders are aligned.

How many disjoint and fragmented programming models do "we" really
need.. (I don't think SE falls into this category, but if we have a
PHI and Intel backend.. why can't it be used)



On Tue, Apr 26, 2016 at 1:38 AM, Chandler Carruth <chandlerc at gmail.com>
wrote:
> On Mon, Apr 25, 2016 at 12:14 PM C Bergström <cbergstrom at
pathscale.com>
> wrote:
>>
>> 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.
>
>
> It isn't that any of these points are invalid, it's just that I
don't think
> we know how or if these projects have a useful overlap to extract and keep
> separate. That was the whole point of my email suggesting that we
shouldn't
> try to force some hypothetical refactoring that we don't even know will
work
> to happen. Several serious technical challenges have been raised with doing
> this refactoring, so its not just avoiding it for the sake of avoiding it.
>
> Even if/when these issues are sorted out and it is feasible to refactor
> things to have a common layer, it still isn't clear whether the overlap
is
> actually that useful. I think we're over analyzing and designing this
when
> we don't even have the code in place to see if there is an interesting
> problem to solve here.