[cfe-dev] [Openmp-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries
Jason Henline via cfe-dev
cfe-dev at lists.llvm.org
Mon Mar 28 11:43:36 PDT 2016
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/cfe-dev/attachments/20160328/85c00310/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160328/85c00310/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160328/85c00310/attachment-0001.gif>
More information about the cfe-dev
mailing list