Hello Martin, I have replied in-line.
On Tue, Mar 24, 2020 at 7:36 PM Martin Jambor <mjam...@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 >
