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

Tue Mar 15 08:59:16 PDT 2016

Hi

Sorry for replying to this thread late - I see that most of the questions
have already found an answer.
As Jim, I am also very happy to hear about Google's work on accelerators.

A couple of notes that caught my eye before going into the integration
discussion:

> provides an open-source alternative to the CUDA runtime library.

Interesting: this still means that you have to go through the CUDA driver
API, right?
I am specifically referring to what is described here:
http://docs.nvidia.com/cuda/cuda-driver-api/#axzz42zF30dZw

libomptarget's rtl library for cuda-enabled device uses the CUDA driver API
directly, not the CUDA runtime library.

>  However, if it turns out that the needs of OpenMP are too specialized to
fit well in a generic parallelism project,

Of course, the libomptarget interface was designed to support OpenMP, not
*any* parallelism project. It is still very general, as the OpenMP
programming language is, and independent of any acceleration type because
of the huge multi-company and users interest in the language.

> execute data-parallel kernels written in the OpenCL or CUDA
kernel languages.

Libomptarget does not currently have an OpenCL interface in its
device-dependent RTL list. However, I am pretty sure that other companies
working on OpenCL (ARM? AMD?) would be interested in having this, as well
as a clang/llvm path that is capable of going from OpenMP to their native
languages.

About integration of the two project:

- If I read Chandler's comment correctly, I do agree that we do not need to
force coupling between the two libraries.

- libomptarget could add a RTL plug-in which interfaces to StreamExecutor.
My question is: what does StreamExecutor do additionally from the current
CUDA RTL implementation? I would be specifically interested in
performance-related points here.
To do this, StreamExecutor would need to implement the interface that is
defined between the target-agnostic part of libomptarget and the
target-dependent part. What would be the interest of StreamExecutor in
doing this?

Finally, one interesting bit about OpenMP is that it does not expose (in
the language) any CUDA-like mechanisms like streams. The user can specify
that certain tasks (e.g. target data-parallel tasks running on a device)
can be executed asynchronously and can define dependencies between them.
Under the hood, libomptarget will make extensive use of CUDA streams to
satisfy dependencies living exclusively on the GPU, but the user does not
get exposed to it.

I hope this helps bringing the discussion forward.

Thanks!

-- Carlo

From:	"Cownie, James H via llvm-dev" <llvm-dev at lists.llvm.org>
To:	Chandler Carruth <chandlerc at google.com>, Jason Henline
            <jhen at google.com>, C Bergström <cbergstrom at pathscale.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>
Date:	03/15/2016 07:41 AM
Subject:	Re: [llvm-dev] [cfe-dev] [Openmp-dev] RFC: Proposing an LLVM
            subproject for parallelism runtime and support libraries
Sent by:	"llvm-dev" <llvm-dev-bounces at lists.llvm.org>

OK, thanks.

-- Jim

James Cownie <james.h.cownie at intel.com>
SSG/DPD/TCAR (Technical Computing, Analyzers and Runtimes)
Tel: +44 117 9071438

From: Chandler Carruth [mailto:chandlerc at google.com]
Sent: Tuesday, March 15, 2016 11:28 AM
To: Cownie, James H <james.h.cownie at intel.com>; Jason Henline
<jhen at google.com>; C Bergström <cbergstrom at pathscale.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>; cfe-dev <cfe-dev at lists.llvm.org>;
openmp-dev at lists.llvm.org
Subject: Re: [cfe-dev] [Openmp-dev] RFC: Proposing an LLVM subproject for
parallelism runtime and support libraries

On Tue, Mar 15, 2016 at 12:13 PM Cownie, James H <james.h.cownie at intel.com>
wrote:
 Chandler,

 That raises a more meta-question for me, which is “Why should
 StreamExecutor be in LLVM at all?”

 AFAICS, with you approach

 ·         It is not a runtime library whose interface the compiler needs
 to understand.
The original email pretty clearly spells out how it is specifically
intended to be a target for the compiler?

 ·         It does not depend on any LLVM runtime libraries.

 ·         It is expected to be used with out-of-tree plugins.
Note that this doesn't mean there won't be in-tree plugins. It's analogous
to how LLVM supports out-of-tree targets.

 If I got all of that right, what connection does it have with LLVM that
 makes having it in the LLVM tree necessary, or an improvement over simply
 having it on github (or whatever your favourite open-source hosting
 location is)?
If there were nothing compiler related to it, then the argument would be
much more tenuous. But I think there is a great deal of compiler relevance
here.

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160315/a96b5448/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/llvm-dev/attachments/20160315/a96b5448/attachment.gif>