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

Jason Henline via llvm-dev
Mon, 28 Mar 2016 18:47:44 -0000

Alexandre,

Thanks for further shedding some light on the way OpenMP handles
dependencies between tasks. I'm sorry for leaving that out of my document,
it was just because I didn't know much about the way OpenMP handled its
workflows.

On Mon, Mar 28, 2016 at 11:43 AM Jason Henline <jhen at google.com> wrote:

> Hi Carlo,
>
> Thanks for helping to clarify this point about libomptarget vs liboffload,
> I have been getting confused about it myself. I think the open question
> concerns libomptarget not liboffload (others can correct me if I have
> misunderstood). My analysis from looking through the code was that
> libomptarget had some similarities with the platform support in SE, so I
> just wanted to consider how those two libraries compared. I didn't do a
> comparison with liboffload.
>
> On Mon, Mar 28, 2016 at 11:11 AM Carlo Bertolli <cbertol at
us.ibm.com>
> wrote:
>
>> Hi
>>
>> Reading through the comments: both Chris and Chandler referenced to
>> liboffload, while I thought the subject of conversation was
libomptarget
>> and SE.
>> I am being picky about names because liboffload is a library available
as
>> part of omp (llvm's openmp runtime library) that, I believe, only
targets
>> Intel Xeon Phi.
>>
>> Did you mean liboffload or libomptarget?
>>
>>
>> Thanks
>>
>> -- Carlo
>>
>> [image: Inactive hide details for Alexandre Eichenberger via Openmp-dev
>> ---03/28/2016 01:44:12 PM---Jason,]Alexandre Eichenberger via
Openmp-dev
>> ---03/28/2016 01:44:12 PM---Jason,
>>
>> From: Alexandre Eichenberger via Openmp-dev <openmp-dev at
lists.llvm.org>
>> To: jhen at google.com
>> Cc: llvm-dev at lists.llvm.org, cfe-dev at lists.llvm.org,
>> openmp-dev at lists.llvm.org
>> Date: 03/28/2016 01:44 PM
>>
>>
>> Subject: Re: [Openmp-dev] [cfe-dev] RFC: Proposing an LLVM subproject
>> for parallelism runtime and support libraries
>>
>> Sent by: "Openmp-dev" <openmp-dev-bounces at
lists.llvm.org>
>> ------------------------------
>>
>>
>>
>>
>> Jason,
>>
>> I concur with your decision since OMP and StreamExecutor fundamentally
>> differ in how dependences between consecutive tasks are expressed. OMP
uses
>> task dependences to express constraint ordering between tasks that
execute
>> on the host and/or on a particular device. Obviously, a stream is a DAG
but
>> with very specific constraints (one linear ordering per stream),
whereas
>> DAG generated by OMP dependences are arbitrary DAGs. This is not a
jugement
>> statement, as in many ways stream are much more friendly to GPUs, it is
>> just a decision that the OMP and StreamExecutor "language
experts" settled
>> on a different language expressivity/efficiency data point.
>>
>> I read your blog on the similarities and differences with great
interest.
>> I may venture to add another overlooked difference: OMP maps objects
with
>> references counts (e.g. first time an object is mapped, its ref count
is
>> zero, and the alloc on device and memory copy will occur; further
nested
>> map will not generate any alloc and/or communication). In summary, OMP
>> primarily uses a dictionary of mapped variables to manage allocation
and
>> data transfer, whereas StreamExecutor it appears to explicitly allocate
and
>> move data.
>>
>> Thanks for your work on this, much appreciated
>>
>> Alexandre
>>
>>
>>
-----------------------------------------------------------------------------------------------------
>> Alexandre Eichenberger, Master Inventor, Advanced Compiler Technologies
>> - research: compiler optimization (OpenMP, multithreading, SIMD)
>> - info: alexe at us.ibm.com http://www.research.ibm.com/people/a/alexe
>> - phone: 914-945-1812 (work) 914-312-3618 (cell)
>>
>>
>> ----- Original message -----
>> From: Jason Henline via Openmp-dev <openmp-dev at lists.llvm.org>
>> Sent by: "Openmp-dev" <openmp-dev-bounces at
lists.llvm.org>
>> To: Andrey Bokhanko <andreybokhanko at gmail.com>, Chandler
Carruth <
>> chandlerc at google.com>
>> Cc: llvm-dev <llvm-dev at lists.llvm.org>, cfe-dev <cfe-dev at
lists.llvm.org>,
>> "openmp-dev at lists.llvm.org" <openmp-dev at
lists.llvm.org>
>> Subject: Re: [Openmp-dev] [cfe-dev] RFC: Proposing an LLVM subproject
for
>> parallelism runtime and support libraries
>> Date: Mon, Mar 28, 2016 12:38 PM
>>
>> I did a more thorough read through liboffload and wrote up a more
>> detailed doc describing how StreamExecutor platforms relate to
libomptarget
>> RTL interfaces. The doc also describes why the lack of support for
streams
>> in libomptarget makes it impossible to implement some of the most
important
>> StreamExecutor platforms in terms of libomptarget (
>>
*https://github.com/henline/streamexecutordoc/blob/master/se_and_openmp.rst*
>>
<https://github.com/henline/streamexecutordoc/blob/master/se_and_openmp.rst>).
>> When I was originally optimistic about using liboffload to implement
>> StreamExecutor platforms, I was not aware of this issue with streams.
>> Thanks to Carlo Bertolli for bringing this to my attention.
>>
>> After having looked in detail at the liboffload code, it sounds like
the
>> best thing to do at this point is to keep StreamExecutor and liboffload
>> separate, but to leave the door open to implement future StreamExecutor
>> platforms in terms of liboffload. From the recent messages on this
subject
>> from Carlo and Andrey it seems like there is a general consensus on
this,
>> so I would like to move forward with the StreamExecutor project in this
>> spirit.
>>
>> On Tue, Mar 15, 2016 at 5:09 PM Jason Henline <*jhen at google.com*
>> <jhen at google.com>> wrote:
>>
>>    I created a GitHub repo that contains the documentation I have been
>>    creating for StreamExecutor.
>>    *https://github.com/henline/streamexecutordoc*
>>    <https://github.com/henline/streamexecutordoc>
>>
>>    It contains the design docs from the original email in this thread,
>>    and it contains a new doc I just made that gives a more detailed
sketch of
>>    the StreamExecutor platform plugin interface. This shows which
methods must
>>    be implemented to support a new platform in StreamExecutor, or to
provide a
>>    new implementation for an existing platform (e.g. using liboffload
to
>>    implement the CUDA platform).
>>
>>    I wrote up this doc in response to a lot of good questions I am
>>    getting about the details of how StreamExecutor might work with the
code
>>    OpenMP already has in place.
>>
>>    Best Regards,
>>    -Jason
>>
>>    On Tue, Mar 15, 2016 at 12:28 PM Andrey Bokhanko <
>>    *andreybokhanko at gmail.com* <andreybokhanko at
gmail.com>> wrote:
>>    Hola Chandler,
>>
>>    On Tue, Mar 15, 2016 at 1:44 PM, Chandler Carruth via Openmp-dev
<
>>    *openmp-dev at lists.llvm.org* <openmp-dev at
lists.llvm.org>> wrote:
>>       It seems like if the OpenMP folks want to add a liboffload plugin
>>       to StreamExecutor, that would be an awesome additional platform,
but I
>>       don't see why we need to force the coupling here.
>>
>>    Let me give you a reason: while user-facing sides of StreamExecutor
>>    and OpenMP are quite different (and each warrants its place under
the
>>    sun!), internal SE's offloading interface and liboffload are
doing exactly
>>    the same thing. Why we want to duplicate code? As previous replies
>>    demonstrated, SE can't serve OpenMP's needs, while
liboffload API seems to
>>    be general enough to serve SE well (though this has to be verified,
of
>>    course -- as I understand, Jason is going to do this).
>>
>>    Sure, there is no "must have need" to couple SE and
liboffload, but
>>    this sounds like a solid software engineering decision to me. Or,
quoting
>>    Jason, who said this much better than me:
>>
>>    > Although OpenMP and StreamExecutor support different
programming
>>    models,
>>    > some of the work they perform under the hood will likely be
very
>>    similar.
>>    > By sharing code and domain expertise, both projects will be
>>    improved and
>>    > strengthened as their capabilities are expanded. The
StreamExecutor
>>    > community looks forward to much collaboration and discussion
with
>>    OpenMP
>>    > about the best places and ways to cooperate.
>>
>>    Espere veure't demà!
>>
>>    Yours,
>>    Andrey
>>    ====>>    Enginyer de Software
>>    Intel Compiler Team
>>
>> _______________________________________________
>> Openmp-dev mailing list
>> Openmp-dev at lists.llvm.org
>> *http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev*
>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev>
>>
>> _______________________________________________
>> 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/20160328/1843518c/attachment.html>