[Openmp-dev] OpenMP 4 offloading status

C Bergström via Openmp-dev openmp-dev at lists.llvm.org
Fri Jun 17 01:25:01 PDT 2016


#1 I think everyone around here is a bit too sensitive

#2 I'll do my best to either:
a. Contribute some headers which directly show the API's I'm talking about
or
b. Some docs which give enough examples and detail that what I'm
talking is tangible.

At that point we can compare 1:1 with how things are in the code
review and maybe have actionable items.
---------------
In general - if you want multiple programming models to mix and
interact with each other in the same program (CUDA+OMP for example)
then it's probably best (required??) for them to all lower down to the
same runtime. Lets call this "Complex use case #1" (My primary
motivation for trying to have everyone play nice together)

One step further is
Mixing multiple devices - Is it possible to load balance CPU+GPU or
GPU+PHI,HSA device+NVIDIA GPU or GPU+FGPA (I realize this is going
quite far and probably not a high priority.. just tossing it out)

The CPU+GPU *is* however a pretty common thought and frequently a
source of wasted resources.. I don't have an immediate solution on
this that doesn't result in significant reductions performance loss..



On Fri, Jun 17, 2016 at 2:34 PM, Hahnfeld, Jonas
<Hahnfeld at itc.rwth-aachen.de> wrote:
> Ok, so let's focus on your constructive points.
>
>> -----Original Message-----
>> From: Openmp-dev [mailto:openmp-dev-bounces at lists.llvm.org] On Behalf
>> Of C Bergström via Openmp-dev
>> Sent: Thursday, June 16, 2016 8:06 PM
>> To: Hal Finkel
>> Cc: LLVM-OpenMP (openmp-dev at lists.llvm.org)
>> Subject: Re: [Openmp-dev] OpenMP 4 offloading status
>>
>> On Fri, Jun 17, 2016 at 1:58 AM, Hal Finkel <hfinkel at anl.gov> wrote:
>> > ----- Original Message -----
>> >> From: "C Bergström via Openmp-dev" <openmp-dev at lists.llvm.org>
>> >> To: "Samuel Antão" <samuelfantao at gmail.com>
>> >> Cc: "LLVM-OpenMP (openmp-dev at lists.llvm.org)"
>> >> <openmp-dev at lists.llvm.org>
>> >> Sent: Thursday, June 16, 2016 12:55:01 PM
>> >> Subject: Re: [Openmp-dev] OpenMP 4 offloading status
>> >>
>> >> So it's not lost or forgotten -
>> >>
>> >> If the libomptarget is the same thing I'm thinking it is, then it
>> >> certainly hasn't had all my comments and feedback addressed.
>> >>
>> >> 1) The design is not friendly to adding more targets
>
> Full disagree: Add a new RTL and implement the methods described in the interface between libomptarget and its RTLs - simple as that.
>
>> >> 2) If that offloading is meant to be available to another programming
>> >> model, it should be abstracted to provide a bit more clean
>> >> abstraction instead of just zero layer over the OMP API.
>
> Well, it wasn't meant to if I got this correctly.  That's why I think the current level of abstraction is just right.
> Also, they didn't start coding without a plan but first put together a well-thought design document. That was a joint effort by multiple companies involved in the OpenMP standard and its implementation.
>
> Coming back to your wish of abstraction: The interface of the RTLs for example consists of the following methods: __tgt_rtl_data_alloc and __tgt_rtl_data_retrieve
> Please tell me
> 1) how this is "just zero layer over the OMP API" and
> 2) what your concrete and detailed proposal would be.
> I have read your mails about "3 layer abstraction" but they have all been focusing on a very high-level view without a concrete design that someone could evaluate or even think of.
>
>> >>
>> >> Lastly and it may be just my opinion, but the way that it's actually
>> >> coded looks like some 1st year C programmer just got his license to
>> >> code.
>> >
>> > Given that I doubt that's literally true, let's keep the criticism constructive,
>> please. Making comments like this only detracts from your more-
>> constructive points.
>
> Completely agree with Hal here: Getting personal is surely not the right way to discuss on technical matters.
> (I've already worked on the code and looked into implementing OMPT which worked quite good. Which means that the design can't be complete non-sense...)
>
>>
>> So for the record all my comments seem pragmatically ignored. #meh
>
> All right, I've commented on the technical topics above.
>
>>
>> I gave specific comments on that patch for a handful of the nits.
>> Regardless of my tone - I'd love to see if it passes clang/llvm coding
>> standards, clang-tidy or lint..
>
> Ehm no, that's just not how it works in open-source communities: Be respectful to the others involved in a discussion.
> (just another random note: you didn't even say sorry and don't seem to change your behavior...)
>
> As for what you'd love to see: Just look into it - that's the power of open source ;-)
>
> Cheers,
> Jonas
>
>> _______________________________________________
>> Openmp-dev mailing list
>> Openmp-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev


More information about the Openmp-dev mailing list