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

On Tue, Mar 29, 2016 at 1:12 AM, Mehdi Amini via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> Hi Jason,
>
> This is probably because I'm not aware of the details, but it was
claimed in
> this thread that liboffload can target Xeon Phi and Nvidia GPUs. Adding a
> new library that the compiler has to be aware of has to bring significant
> benefit.
> So it is not clear to me yet why the compiler should target two different
> runtime libraries that seems to have large chunk of overlapping
> functionalities.
> On a high-level view, these libraries seems to have the same goals with
> respect to what they provide to the compiler.
>
> Can you elaborate?
(Ignore this please)

To butt in with a peanut gallery comment - I suspect it's because
liboffload is really just providing a bare set of non-portable API
mostly tailored to OpenMP4. Having it support any other programming
model is probably going to take real work on the part of refactoring
"liboffload". (*cough* *cough* good design)

In the end I pessimistically suspect each programming model wanting
inclusion will reinvent the wheel and make the same argument each
time. So we'll end up with lots of libraries doing mostly the same
thing, duplicate code/support.. etc

> On Mar 28, 2016, at 10:18 AM, C Bergström <cbergstrom at
pathscale.com> wrote:
> 
> On Tue, Mar 29, 2016 at 1:12 AM, Mehdi Amini via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
>> Hi Jason,
>> 
>> This is probably because I'm not aware of the details, but it was
claimed in
>> this thread that liboffload can target Xeon Phi and Nvidia GPUs. Adding
a
>> new library that the compiler has to be aware of has to bring
significant
>> benefit.
>> So it is not clear to me yet why the compiler should target two
different
>> runtime libraries that seems to have large chunk of overlapping
>> functionalities.
>> On a high-level view, these libraries seems to have the same goals with
>> respect to what they provide to the compiler.
>> 
>> Can you elaborate?
> 
> (Ignore this please)
> 
> To butt in with a peanut gallery comment - I suspect it's because
> liboffload is really just providing a bare set of non-portable API
> mostly tailored to OpenMP4.
That can be a valid argument. If indeed liboffload is limited by its original
design and a new design can be useful to a wider range of model/target, then the
path forward should rather be to replace liboffload.
IMO, duplicating libraries/API that the compiler has to be aware of should be
really motivated by specificities provided by each library that can't be
unified in a single library/API.

-- 
Mehdi

 

> Having it support any other programming
> model is probably going to take real work on the part of refactoring
> "liboffload". (*cough* *cough* good design)
> 
> In the end I pessimistically suspect each programming model wanting
> inclusion will reinvent the wheel and make the same argument each
> time. So we'll end up with lots of libraries doing mostly the same
> thing, duplicate code/support.. etc

On Tue, Mar 29, 2016 at 1:22 AM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
>
>> On Mar 28, 2016, at 10:18 AM, C Bergström <cbergstrom at
pathscale.com> wrote:
>>
>> On Tue, Mar 29, 2016 at 1:12 AM, Mehdi Amini via cfe-dev
>> <cfe-dev at lists.llvm.org> wrote:
>>> Hi Jason,
>>>
>>> This is probably because I'm not aware of the details, but it
was claimed in
>>> this thread that liboffload can target Xeon Phi and Nvidia GPUs.
Adding a
>>> new library that the compiler has to be aware of has to bring
significant
>>> benefit.
>>> So it is not clear to me yet why the compiler should target two
different
>>> runtime libraries that seems to have large chunk of overlapping
>>> functionalities.
>>> On a high-level view, these libraries seems to have the same goals
with
>>> respect to what they provide to the compiler.
>>>
>>> Can you elaborate?
>>
>> (Ignore this please)
>>
>> To butt in with a peanut gallery comment - I suspect it's because
>> liboffload is really just providing a bare set of non-portable API
>> mostly tailored to OpenMP4.
>
> That can be a valid argument. If indeed liboffload is limited by its
original design and a new design can be useful to a wider range of model/target,
then the path forward should rather be to replace liboffload.
> IMO, duplicating libraries/API that the compiler has to be aware of should
be really motivated by specificities provided by each library that can't be
unified in a single library/API.
I fall into the camp that it's StreamExecutor's devs job to play nice
and refactor what we have today instead of trying to reinvent the
wheel because they don't have time for something else. My opinion
probably doesn't count for much and probably isn't what other people
will say around here.

(I digress) At the same time I'm empathetic, from my high level
perspective liboffload sucks. (It ?may? be good enough to do
(minimal?) ___________ ???? OMP4 needs, but what can it do beyond
that..) The only way for it to suck less is for others with different
perspective and skills to come in and help out though. (I mean the
current liboffload devs did the best they could for their needs)