GSoC Separate Host Process Offloading

GSoC Separate Host Process Offloading

[Prasad, Adi]

[-- Attachment #1: Type: text/plain, Size: 722 bytes --]

Hi all,

I’m Adi Prasad, a 2nd year Computing student at Imperial College London, interested in doing the Separate Host Process Offloading GSoC project this summer.

First off, I’m aware I’m getting in touch very late; I have been busy up until now with a university project deadline. I am however determined to work as hard as I need to this week to catch up for my late start; I hope you are still willing to consider me.

I was wondering if the devs had any recommendations for starter issues to work on (or simpler tasks like tests and documentation) that would help me familiarise myself with the relevant code?

Thank you for reading this, and I will stay in touch as I develop my proposal!

Thanks,
Adi

Re: GSoC Separate Host Process Offloading

[Thomas Schwinge]

Hi Adi!

On 2023-03-28T20:39:04+0000, "Prasad, Adi via Gcc" <gcc@gcc.gnu.org> wrote:
> I’m Adi Prasad, a 2nd year Computing student at Imperial College London, interested in doing the Separate Host Process Offloading GSoC project this summer.

Greak, and welcome to GCC!  :-)

> First off, I’m aware I’m getting in touch very late; I have been busy up until now with a university project deadline. I am however determined to work as hard as I need to this week to catch up for my late start; I hope you are still willing to consider me.

No worries, you're to too late; no decisions have been made, yet.

> I was wondering if the devs had any recommendations for starter issues to work on (or simpler tasks like tests and documentation) that would help me familiarise myself with the relevant code?

Building GCC and producing test results would be one obvious first task.
<https://gcc.gnu.org/wiki/SummerOfCode> and
<https://gcc.gnu.org/wiki/#Getting_Started_with_GCC_Development> have
some pointers to get started.  If you have specific questions, we're
happy to help, of course.

Then, get familiar with the basic concepts of code offloading in GCC.
<https://gcc.gnu.org/wiki/Offloading> is the best (only?) we have,
unfortunately, and it's somewhat out of date, so beware, sorry.  Looking
at existing libgomp plugins may help: 'libgomp/plugin/plugin-*.c' (The
'GOMP_OFFLOAD_[...]' functions implement the offloading plugin API), and
actually also the very simple 'libgomp/oacc-host.c'.  That's essentially
the API you need to care about (for OpenACC; but OpenMP 'target' also
won't require much more, for a start).

Make some thoughts (or actual experiments) about how we could
use/implement a separate host process for code offloading.

> Thank you for reading this, and I will stay in touch as I develop my proposal!

Yes, please do.  In particular, think about a timeline for your proposal.


Grüße
 Thomas
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

Re: GSoC Separate Host Process Offloading

[Prasad, Adi]

[-- Attachment #1: Type: text/plain, Size: 4528 bytes --]

Hi Thomas,

Thanks for the info - I’ve read through the page on “Offloading” and looked at some code and have successfully built and tested GCC from source. I’ll also watch the videos on LTO on the Getting Started page, as offloading seems to be quite intertwined with LTO.

Before I start writing the proposal, I came up with a rough list of TODOs that I wanted to run by you (not necessarily in this order; I will order things in a way that makes it easiest to test):

  1.  Add an —enable-offload-targets option for a separate host process
  2.  Rework lto-wrapper so that if the separate host process target is enabled, it finds and calls a mkoffload for the host architecture instead of looking for an offloading compiler’s mkoffload; then write a mkoffload tool for a separate host process.
  3.  Write a libgomp plugin for separate host processes
  4.  Document changes, certify Developer Certificate of Origin, produce a ChangeLog etc according to https://gcc.gnu.org/wiki/GettingStarted#Tutorials.2C_HOWTOs and https://gcc.gnu.org/contribute.html#patches
  5.  Submit to the mailing list and respond to any requests for changes
  6.  Commit! :)

One thing I was wondering that I may be missing - the offloading docs state that the patch for adding the Intel MIC target have a “runtime offloading library” called Intel MIC. I haven’t been able to figure out the purpose of this (my best guess is it’s used to implement the libgomp plugin?), and whether it’s Intel-specific or needed for multiple targets.

Finally, I was wondering if, having built and tested GCC, there are now any patches, tests, or docs that I can work on?


Thanks so much for the help!

Adi

________________________________
From: Thomas Schwinge <thomas@codesourcery.com>
Sent: Wednesday, March 29, 2023 9:39:02 PM
To: Prasad, Adi <adi.prasad21@imperial.ac.uk>
Cc: gcc@gcc.gnu.org <gcc@gcc.gnu.org>; Tobias Burnus <tobias@codesourcery.com>
Subject: Re: GSoC Separate Host Process Offloading


*******************
This email originates from outside Imperial. Do not click on links and attachments unless you recognise the sender.
If you trust the sender, add them to your safe senders list https://spam.ic.ac.uk/SpamConsole/Senders.aspx to disable email stamping for this address.
*******************
Hi Adi!

On 2023-03-28T20:39:04+0000, "Prasad, Adi via Gcc" <gcc@gcc.gnu.org> wrote:
> I’m Adi Prasad, a 2nd year Computing student at Imperial College London, interested in doing the Separate Host Process Offloading GSoC project this summer.

Greak, and welcome to GCC!  :-)

> First off, I’m aware I’m getting in touch very late; I have been busy up until now with a university project deadline. I am however determined to work as hard as I need to this week to catch up for my late start; I hope you are still willing to consider me.

No worries, you're to too late; no decisions have been made, yet.

> I was wondering if the devs had any recommendations for starter issues to work on (or simpler tasks like tests and documentation) that would help me familiarise myself with the relevant code?

Building GCC and producing test results would be one obvious first task.
<https://gcc.gnu.org/wiki/SummerOfCode> and
<https://gcc.gnu.org/wiki/#Getting_Started_with_GCC_Development> have
some pointers to get started.  If you have specific questions, we're
happy to help, of course.

Then, get familiar with the basic concepts of code offloading in GCC.
<https://gcc.gnu.org/wiki/Offloading> is the best (only?) we have,
unfortunately, and it's somewhat out of date, so beware, sorry.  Looking
at existing libgomp plugins may help: 'libgomp/plugin/plugin-*.c' (The
'GOMP_OFFLOAD_[...]' functions implement the offloading plugin API), and
actually also the very simple 'libgomp/oacc-host.c'.  That's essentially
the API you need to care about (for OpenACC; but OpenMP 'target' also
won't require much more, for a start).

Make some thoughts (or actual experiments) about how we could
use/implement a separate host process for code offloading.

> Thank you for reading this, and I will stay in touch as I develop my proposal!

Yes, please do.  In particular, think about a timeline for your proposal.


Grüße
 Thomas
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

Re: GSoC Separate Host Process Offloading

[Tobias Burnus]

Hi Adi,

On 31.03.23 14:35, Prasad, Adi wrote:
> Rework lto-wrapper so that if the separate host process target is
> enabled, it finds and calls a mkoffload for the host architecture
> instead of looking for an offloading compiler’s mkoffload; then write
> a mkoffload tool for a separate host process.

Note that multiple offload targets are possible. For instance, on
Debian/Ubuntu, 'gcc -v' shows:
'OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa' and lto-wrapper then
cycles through those, finding the offloading compiler in
$PATH/accel/<triple>/mkoffload

Example: x86_64-none-linux-gnu/12.2.1/accel/amdgcn-amdhsa/mkoffload

Thus, if you install it to 'x86_64-none-linux-gnu' and add it to
OFFLOAD_TARGET_NAMES,* it will work; albeit, we probably want to have
some special handling in gcc.cc to avoid host-process offloading by
default and permit something like -foffload=host instead of having to
specify -foffload=x86_64-none-linux-gnu

(For those flags, see
https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#index-foffload )

(* it is automatically when adding it to --enable-offload-targets=...
when configuring the non-offloading compiler.)

> 3. Write a libgomp plugin for separate host processes
> 4. Document changes, certify Developer Certificate of Origin, produce
> a ChangeLog etc according
> tohttps://gcc.gnu.org/wiki/GettingStarted#Tutorials.2C_HOWTOsandhttps://gcc.gnu.org/contribute.html#patches
I think it would be useful to start posting patches early – such that
they can be reviewed and discussed. Thus, this is not really the 4th and
5th item.
> 5. Submit to the mailing list and respond to any requests for changes
* * *
>
> One thing I was wondering that I may be missing - the offloading docs
> state that the patch for adding the Intel MIC target have a “runtime
> offloading library” called Intel MIC. I haven’t been able to figure
> out the purpose of this (my best guess is it’s used to implement the
> libgomp plugin?), and whether it’s Intel-specific or needed for
> multiple targets.
>
There used to be Intel MIC support – which effectively only used a
simulator, similar to what this project is about, but this time it is
supposed to be generic and not as narrowly focused as the Intel MIC
stub/simulator/target support.

(Intel MIC support was removed.)

> Finally, I was wondering if, having built and tested GCC, there are
> now any patches, tests, or docs that I can work on?
>
For offloading tests, see libgomp/testsuite/ for OpenMP and OpenACC -
albeit for OpenMP, only those tests with 'omp target' actually use
offloading, which can be hostfall back.

They can be run as "make check-target-libgomp" (in the build dir) or by
"cd x86_64-none-linux-gnu/libgomp; make check" – and specific tests can
be run by setting, e.g., RUNTESTFLAGS="fortran.exp" or
RUNTESTFLAGS="c.exp=target-11.c" or ...

No quick idea for work items – maybe I get one – or Thomas does :-)

Tobias

-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

RE: GSoC Separate Host Process Offloading

[Prasad, Adi]

Hi Tobias,
Thanks for the reply!

> 
> Note that multiple offload targets are possible. For instance, on
> Debian/Ubuntu, 'gcc -v' shows:
> 'OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa' and lto-wrapper then
> cycles through those, finding the offloading compiler in
> $PATH/accel/<triple>/mkoffload
> 
> Example: x86_64-none-linux-gnu/12.2.1/accel/amdgcn-amdhsa/mkoffload
> 
> Thus, if you install it to 'x86_64-none-linux-gnu' and add it to
> OFFLOAD_TARGET_NAMES,* it will work; albeit, we probably want to have
> some special handling in gcc.cc to avoid host-process offloading by
> default and permit something like -foffload=host instead of having to
> specify -foffload=x86_64-none-linux-gnu
> 
Understood. Forgive me if I'm misunderstanding this, but I wonder if it might be better to put the new mkoffload in an "accel/host" directory, and add "host" to OFFLOAD_TARGET_NAMES rather than have the specific host e.g. "x86_64-none-linux-gnu"? This would 1) enable the use of "-foffload=host" automatically and 2) distinguish between compiling for the same device on a separate process versus compiling to a separate device with the same architecture and kernel as the host. I can imagine this clash wouldn’t happen in practice, since compiling for a separate host process would target CPUs while compiling for a separate device would target GPUs, but it might be nicer to keep them conceptually separate all the same.

> I think it would be useful to start posting patches early – such that
> they can be reviewed and discussed. Thus, this is not really the 4th and
> 5th item.
>
I can post patches every week instead since my proposal will set a milestone target for each week.
Additionally, what do you think about me doing some other small tasks besides the proposed scope? What I was thinking about specifically was that it might be helpful to get the offloading documentation page up to date and add info on OpenACC.

> No quick idea for work items – maybe I get one – or Thomas does :-)
> 
> Tobias
> 
Thank you so much for all the info, and do let me know if any small tasks come up!
Adi

RE: GSoC Separate Host Process Offloading

[Prasad, Adi]

Hi Tobias and Thomas,
My apologies for the double email; I have an unrelated administrative ask. Would it be possible to provide any past successful GSoC proposals? I'm interested in any thnigs GCC specifically is looking for in proposals (I've seen quite a few generic guides on the web but none specific to GCC).

Thanks,
Adi

> -----Original Message-----
> From: Prasad, Adi
> Sent: Saturday, April 1, 2023 4:16 AM
> To: 'Tobias Burnus' <tobias@codesourcery.com>; Thomas Schwinge
> <thomas@codesourcery.com>
> Cc: gcc@gcc.gnu.org
> Subject: RE: GSoC Separate Host Process Offloading
> 
> Hi Tobias,
> Thanks for the reply!
> 
> >
> > Note that multiple offload targets are possible. For instance, on
> > Debian/Ubuntu, 'gcc -v' shows:
> > 'OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa' and lto-wrapper
> then
> > cycles through those, finding the offloading compiler in
> > $PATH/accel/<triple>/mkoffload
> >
> > Example: x86_64-none-linux-gnu/12.2.1/accel/amdgcn-amdhsa/mkoffload
> >
> > Thus, if you install it to 'x86_64-none-linux-gnu' and add it to
> > OFFLOAD_TARGET_NAMES,* it will work; albeit, we probably want to have
> > some special handling in gcc.cc to avoid host-process offloading by
> > default and permit something like -foffload=host instead of having to
> > specify -foffload=x86_64-none-linux-gnu
> >
> Understood. Forgive me if I'm misunderstanding this, but I wonder if it might be
> better to put the new mkoffload in an "accel/host" directory, and add "host" to
> OFFLOAD_TARGET_NAMES rather than have the specific host e.g. "x86_64-none-
> linux-gnu"? This would 1) enable the use of "-foffload=host" automatically and 2)
> distinguish between compiling for the same device on a separate process versus
> compiling to a separate device with the same architecture and kernel as the host.
> I can imagine this clash wouldn’t happen in practice, since compiling for a
> separate host process would target CPUs while compiling for a separate device
> would target GPUs, but it might be nicer to keep them conceptually separate all
> the same.
> 
> > I think it would be useful to start posting patches early – such that
> > they can be reviewed and discussed. Thus, this is not really the 4th
> > and 5th item.
> >
> I can post patches every week instead since my proposal will set a milestone
> target for each week.
> Additionally, what do you think about me doing some other small tasks besides
> the proposed scope? What I was thinking about specifically was that it might be
> helpful to get the offloading documentation page up to date and add info on
> OpenACC.
> 
> > No quick idea for work items – maybe I get one – or Thomas does :-)
> >
> > Tobias
> >
> Thank you so much for all the info, and do let me know if any small tasks come
> up!
> Adi

Re: GSoC Separate Host Process Offloading

[Prasad, Adi]

[-- Attachment #1: Type: text/plain, Size: 3238 bytes --]

Hi Tobias and Thomas - just wondering if you've had a chance to look at this?

Thanks,
Adi
________________________________
From: Prasad, Adi <adi.prasad21@imperial.ac.uk>
Sent: Saturday, April 1, 2023 5:16 am
To: Tobias Burnus <tobias@codesourcery.com>; Thomas Schwinge <thomas@codesourcery.com>
Cc: gcc@gcc.gnu.org <gcc@gcc.gnu.org>
Subject: RE: GSoC Separate Host Process Offloading

Hi Tobias and Thomas,
My apologies for the double email; I have an unrelated administrative ask. Would it be possible to provide any past successful GSoC proposals? I'm interested in any thnigs GCC specifically is looking for in proposals (I've seen quite a few generic guides on the web but none specific to GCC).

Thanks,
Adi

> -----Original Message-----
> From: Prasad, Adi
> Sent: Saturday, April 1, 2023 4:16 AM
> To: 'Tobias Burnus' <tobias@codesourcery.com>; Thomas Schwinge
> <thomas@codesourcery.com>
> Cc: gcc@gcc.gnu.org
> Subject: RE: GSoC Separate Host Process Offloading
>
> Hi Tobias,
> Thanks for the reply!
>
> >
> > Note that multiple offload targets are possible. For instance, on
> > Debian/Ubuntu, 'gcc -v' shows:
> > 'OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa' and lto-wrapper
> then
> > cycles through those, finding the offloading compiler in
> > $PATH/accel/<triple>/mkoffload
> >
> > Example: x86_64-none-linux-gnu/12.2.1/accel/amdgcn-amdhsa/mkoffload
> >
> > Thus, if you install it to 'x86_64-none-linux-gnu' and add it to
> > OFFLOAD_TARGET_NAMES,* it will work; albeit, we probably want to have
> > some special handling in gcc.cc to avoid host-process offloading by
> > default and permit something like -foffload=host instead of having to
> > specify -foffload=x86_64-none-linux-gnu
> >
> Understood. Forgive me if I'm misunderstanding this, but I wonder if it might be
> better to put the new mkoffload in an "accel/host" directory, and add "host" to
> OFFLOAD_TARGET_NAMES rather than have the specific host e.g. "x86_64-none-
> linux-gnu"? This would 1) enable the use of "-foffload=host" automatically and 2)
> distinguish between compiling for the same device on a separate process versus
> compiling to a separate device with the same architecture and kernel as the host.
> I can imagine this clash wouldn’t happen in practice, since compiling for a
> separate host process would target CPUs while compiling for a separate device
> would target GPUs, but it might be nicer to keep them conceptually separate all
> the same.
>
> > I think it would be useful to start posting patches early – such that
> > they can be reviewed and discussed. Thus, this is not really the 4th
> > and 5th item.
> >
> I can post patches every week instead since my proposal will set a milestone
> target for each week.
> Additionally, what do you think about me doing some other small tasks besides
> the proposed scope? What I was thinking about specifically was that it might be
> helpful to get the offloading documentation page up to date and add info on
> OpenACC.
>
> > No quick idea for work items – maybe I get one – or Thomas does :-)
> >
> > Tobias
> >
> Thank you so much for all the info, and do let me know if any small tasks come
> up!
> Adi

RE: GSoC Separate Host Process Offloading

[Martin Jambor]

Hello,

On Sat, Apr 01 2023, Prasad, Adi via Gcc wrote:
> Hi Tobias and Thomas,
>
> My apologies for the double email; I have an unrelated administrative
> ask. Would it be possible to provide any past successful GSoC
> proposals? I'm interested in any thnigs GCC specifically is looking
> for in proposals (I've seen quite a few generic guides on the web but
> none specific to GCC).

Unfortunately no, not without seeking permission of their authors first.

But generally speaking, if you can demonstrate that you have the skills
and ability to understand the offloading architecture, the current
relevant sources (not necessarily in depth but more-or-less correctly)
and that you have the C/C++ coding skills to be able to successfully
change them, you are likely to be selected (depending on how many slots
we get from Google, of course).

One way to demonstrate it is to provide good milestones in your proposal
and a timeline which will demonstrate that you already have an idea what
you would be working on in the first few weeks, beyond setting things up
and learning stuff.

>
> Thanks,
> Adi
>
>> -----Original Message-----
>> From: Prasad, Adi
>> Sent: Saturday, April 1, 2023 4:16 AM
>> To: 'Tobias Burnus' <tobias@codesourcery.com>; Thomas Schwinge
>> <thomas@codesourcery.com>
>> Cc: gcc@gcc.gnu.org
>> Subject: RE: GSoC Separate Host Process Offloading
>> 
>> Hi Tobias,
>> Thanks for the reply!
>> 
>> >
>> > Note that multiple offload targets are possible. For instance, on
>> > Debian/Ubuntu, 'gcc -v' shows:
>> > 'OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa' and lto-wrapper
>> then
>> > cycles through those, finding the offloading compiler in
>> > $PATH/accel/<triple>/mkoffload
>> >
>> > Example: x86_64-none-linux-gnu/12.2.1/accel/amdgcn-amdhsa/mkoffload
>> >
>> > Thus, if you install it to 'x86_64-none-linux-gnu' and add it to
>> > OFFLOAD_TARGET_NAMES,* it will work; albeit, we probably want to have
>> > some special handling in gcc.cc to avoid host-process offloading by
>> > default and permit something like -foffload=host instead of having to
>> > specify -foffload=x86_64-none-linux-gnu
>> >
>> Understood. Forgive me if I'm misunderstanding this, but I wonder if it might be
>> better to put the new mkoffload in an "accel/host" directory, and add "host" to
>> OFFLOAD_TARGET_NAMES rather than have the specific host e.g. "x86_64-none-
>> linux-gnu"? This would 1) enable the use of "-foffload=host" automatically and 2)
>> distinguish between compiling for the same device on a separate process versus
>> compiling to a separate device with the same architecture and kernel as the host.
>> I can imagine this clash wouldn’t happen in practice, since compiling for a
>> separate host process would target CPUs while compiling for a separate device
>> would target GPUs, but it might be nicer to keep them conceptually separate all
>> the same.

These are details which can be tweaked later but yeah, some
simplification will be necessary.

>> 
>> > I think it would be useful to start posting patches early – such that
>> > they can be reviewed and discussed. Thus, this is not really the 4th
>> > and 5th item.
>> >
>> I can post patches every week instead since my proposal will set a milestone
>> target for each week.
>> Additionally, what do you think about me doing some other small tasks besides
>> the proposed scope? What I was thinking about specifically was that it might be
>> helpful to get the offloading documentation page up to date and add info on
>> OpenACC.

Updating documentation would be very welcome but not as part of a GSoC
project, the rules forbid that.

As far as small tasks are concerned, that is always very difficult in
GCC and so we do not really expect all applicants to manage completing
any.  But it is important to demonstrate understanding of the relevant
bits of GCC, for example by asking good questions on this list.

Good luck,

Martin

RE: GSoC Separate Host Process Offloading

[Thomas Schwinge]

Hi Adi!

I've not been able yet to review your items in detail, but it's very good
that you're discussing your ideas!

At least a few comments:

On 2023-04-01T03:16:28+0000, "Prasad, Adi via Gcc" <gcc@gcc.gnu.org> wrote:
> Tobias wrote:
>> [...] permit something like -foffload=host instead of having to
>> specify -foffload=x86_64-none-linux-gnu

Right -- but I'd be happy if initially the latter worked, and then a
'host' variant can be made work incrementally.

> Understood. Forgive me if I'm misunderstanding this, but [...]

No, these are certainly good ideas!  :-) (I can't investigate the details
right now, but surely will, once the time comes.)


Please spend some time on this central question that I'd raised:

| Make some thoughts (or actual experiments) about how we could
| use/implement a separate host process for code offloading.

That is, include in your project proposal (or, discuss here, if there's
still time) your ideas about how to actually implement that.


As Martin wrote, don't worry too much about the specific format of your
application.  It's more important that we're able to see that you're
understanding the scope of the project, timeline, expected difficulties,
and so on.  All within reasonable bounds, of course -- we're all very
well aware of the difficulties of estimating software projects...  Yet,
some plausible timeline, milestones, etc. are necessary in the project
proposal.


Good luck!

Grüße
 Thomas
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955