Re: GSoC: Implementation of OMPD

["y2s1982 ." <y2s1982@gmail.com>]

Hello Martin,

I have replied in-line.

On Tue, Mar 24, 2020 at 7:36 PM Martin Jambor <mjambor@suse.cz> wrote:

> Hi Tony,
>
> sorry for a late reply, things are a bit crazy recently.
>

That's okay. Thanks for reaching back to me. I am still very interested.


> On Sat, Mar 07 2020, y2s1982 . wrote:
> > Hello everyone,
> >
> > My name is Tony Sim. In anticipation to planning for my last summer
> within
> > my degree program, I am considering to take part in the Google Summer of
> > Codes.  In particular, I would like to work on implementing OMPD for GCC
> > and related programs.
> >
> > I have studied CPU and GPU parallel programming in the span of two
> > semesters, which included OpenMP as a significant part of the
> curriculum. I
> > am quite fascinated by its possibilities and would love a chance to learn
> > more while tackling a real-world challenge.
> >
> > I would appreciate any additional information on the project.  It looks
> > very interesting. Really, it sounds like something I wish I had when I
> was
> > taking the course.
> >
>
> The OMPD project idea might be the most ambitious from the whole lot.
> Basically, the goal is to come up with a prototype implementation of
> chapter 5 of OpenMP 5.0 Specification
> (https://www.openmp.org/specifications/), so that OpenMP programs
> compiled with GCC can be debugged in GDB using OpenMP terminology.
>

This is music to my ears. I am eagerly reading up on the documentation,
starting from their section 5 that seems to cover OMPD in detail.


> In order to start you need to understand how OpenMP programs are
> internally structured (compile some a few basic ones with
> -fdump-tree-optimized and then examine the generated dump) and
> especially familiarize yourself with the libgomp library that provides
> essential run-time support to OpenMP programs.  Libgomp is part of GCC
> project, see https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=libgomp.
>

Okay, I will try that. I guess I will try out some simple for loop and
see.  Any particular sections or tips on reading the dump?


> The long-term goal is to implement that chapter 5 in libgomp, so that
> internal structures of libgomp and the run program can be exposed with
> this interface.  Of course, that would be too big a project for one
> summer, so the immediate goal would be to come up with an implementation
> of a subset that would behave well in a given set of contexts... and
> either make it consumable by GDB or at the very least demonstrate that
> it can be done.  Still a lot of work.
>

As you mentioned, the project seems ambitious, and one of the challenges
seemed to be setting a scope. Thank you for providing me with that
guideline.
So, if I may reiterate and make some more assumptions, the scope seems to
be: coming up with a proof-of-concept that may be replicated elsewhere to
complete the integration of OMPD.
This is exactly what I am interested in doing and gain valuable learning
experience while doing so.

>
> If you have any further questions, please feel free to ask.
>

I do have a question.
Debugging a program with OMP was challenging; if anything, the
race-condition alone made reproducing many bugs a probability issue.  I was
taught to give extra care on developing, optimizing, and debugging a
single-thread counterpart first before converting to an OMP application.
Would the OMPD make it possible for programmer to develop an OMP
application from ground-up, or would they still need to design the
single-threaded version first?


> Good luck with your GSoC!
>
> Martin
>