All right, take a seat, I'm going to listen to a talk about OpenMP and GCC, for
forget that these slides are already up in the first-name page for this session, so you
can find the slides there, so you can still take pictures with one, but you can also find
them there.
I start a few words about myself, I'm a contributor to the OpenMP specification and also
to the relevant parts in GCC itself, so offloading OpenMP for Trun, which is how I started
having background-time computational physics, so that I came into contributing to G4 Trun,
otherwise I'll work nowadays for Belieber, Belieber, that's where it gets paid, I've
ever heard, do some work related to toolchains, like compilers, debuggers and so on, and
the other part, you do a bit more on the Linux kernel and related things embedded and
right and so on, that's background, that's which to GCC, in the OpenMP and offloading
part, just seem meanwhile as support or general of OpenMP and OpenMP and OpenMP, there's
a proper complete support of 5.2, of course, some gaps and the larger gaps, but not the
only one, it's missing OpenMP and OpenMP support, so toolchains and debugging, there's
another this link, especially in the first one, you can see a bird's audio, which features
implemented and not an OpenMP, so yes, no, like any second one link there, which is
a first specific version, but in the first link one really says in this version, this
features, supported this basic support, offloading support, Nvidia and NVGPUs, some information
about building them, where to get them, I mean, dist for a server, but there are optional
packages and something so to build them, there's another link in the wiki and, well,
GCC15 is the newest release, which is now almost one year old, and I've recommended
one for MP because a lot of missing features are finally in there, and it's relatively
complete 16, maybe, but let's change this, but a lot of changes here and there, one
of it changes, for instance, the MI300 support, we finally got access to one, thanks to
you as your frorigan, so some idle time, this one could add it, in the talk itself, I will
talk about OpenMP in top, so some examples coming there, and OpenMP, I hope, is supported
in GCC15, only maybe one can say since it's a bit older feature, but it contains most
of the OpenMP's six features and particularly as for France support, and since, on P6,
I guess, most, or several of the other compilers will also support at least the seabersion
of the inter-op, if I can text the latest version, and on the GCC side, planned, is of course
the usual things like bug fixes, filling some gaps on either corner cases or missed items
and some completely missing 5.x features, and with upcoming and work, actually, none
or supposed to be started soon as the next two items are flood performance improvements in
the OMPT, but don't expect too much of this work, I mean, some parts of performance work
of course enter always, but some bigger learnings are expected for the next GCC version,
and well, like always, if OpenMP's awesome, problems going to be it has work come,
code documentation, back reports, and I guess there will be Google some of code this year,
so if someone has an idea of a project, I think help us always work
well, let's move to OpenMP and inter-op is a bit kind of the starting point, one has existing code,
principle does not really need to have OpenMP, it still has some advantages, but it mostly makes sense
if one has OpenMP code, whatever host side of load does not really matter, and one has of course a GPU,
and then there's this nice vendor libraries by vendors like Nvidia, in the end zone, which provides
some optimized version running on the GPU for fast 4 year transformation, basically in the
Alba and so on, and of course one wants to use them, and inter-op makes not a bit easier, or
I will provide some complexity, the compatibility or portability, especially with the OpenMP part,
but they are also in general, and later part, and it comes more important for dependency from
Google's concurrent, so I've picked some example, picking good up, picking C, where there's the
Blast call in the middle, and this example of course one has to transfer data to the device,
and create this streaming object and use it, and part of this one can replace by OpenMP,
so the first one we handled it for social part, which has nothing to do with the inter-op feature,
we copied the data, I'll equate the data on the device, and this example, the MP target one
not initialized on the device, then there are various ways to get the point on the device side,
or it just was choosing the MP get map pointer to get it, and then once it has to create the
stream and so on, which I skipped here and use it, so that's quite nice, but one wants to do more,
and of course OpenMP provides various addition ways of getting things, like allocating memory
directly on the target as a team, or provides allocation, managed memory, at least this
minute extension, you fetch memory, then one can avoid some of these issues, but it's a side
to remark, but now let's go to Inter-op, centre-op, one gets to direct the MP, Inter-op in it,
and at the end destroy, where one has an object, and then one asks, what one wants to have,
the side case target, which provides some basic information about the system, and then one can add,
what this is the preferred type, if it's not available at one time might do anything, if you have
something different, because let's say an MPGP and doesn't have gooda, and or can say device and
proper things, and then one gets an object, if it's available, then one can check what type it is,
run time, interrupt end, so from run time or back in this case, it's gooda like expected,
and then one can also get to, for instance, the device number, but that's not really the most
interesting part of doing it, but come to the more interesting part next time, slide, and the GCC
compiler for Nvidia GPU is gooda, gooda driver hipers supported, find the hip and HSA,
hipers, essentially, gooda except of C, or gooda in the API would change the place by hip,
and the interesting part therefore it's also hip for the Nvidia one is that they have
essentially in the header stay referred to the gooda version so there's no overhead, and therefore
also in GCC site implementing is easy, because actually all the free types that return
exactly the same, which is not the case for hip HSA, and what's available, something on next
life is also that's well defined, and of course depends on the compiler and device and so on
what's really available, well now it gets the more interesting part that's replacing this free
create and destroy, and there one can see, so if you target sync, the case is streaming
object, and then one can obtain using the API routine as shown to get the stream out, and then
at the end one destroys the stream and just waits until the stream is completed, so that's already
make some things, but easier and more, useful here, and let's quickly show that if I'm
looking in the OpenMP manual, not any specification but division, you can add one sees what
is available there, so for gooda's streaming object and the other types, so hip, hip stream,
and some others, and of course it's already first up to make it a bit less library dependent,
and now the really fancy stuff is where you can't do it manually, is if you combine it with OpenMP
with dependencies and as an Corona, so no wait, as an example, so in this example, when initializers
comes from the OpenMP sample document, when initialize the data and has some outgoing dependencies
and then the Interup object, since it then takes those values, one has the dependency, and
likewise, while the calculation is ongoing, one has the outgoing dependency, so the destroy
waits essentially, until the data's ready, and then one can use it later, so that's I think
most interesting feature for Interup lift depend, it's like the unrelated disc sectors example,
but on in the box I show that one can also use it in Fortran, as mentioned, then I also want to
add some hip example, and especially for Fortran site, the nice thing is that hip Fortran is
available as Fortran file, and can very easily just compile it with whatever compiler one has it,
and then use it, could have Fortran is a bit more difficult to get compatible with our compilers
and otherwise it's pretty much the same way. The other thing I want to talk to make it easier to use
variants functions, it's a normal variant, way of doing it, not yet for Interup, optimized, so one
has a base function, and a variant function, which in terms of the arguments, I'm so as identical,
has of course a different name, and then one can define the clear variant, and then another certain
conditions, one does, variant is used, the one I marked with the match clause here, if I'm just
called it, one gets the base function in front, called the base function, but sits before, in this case,
the global variant is used very into a true, then the base function, it actually doesn't
call it a base function, but the function, a variant function, and there are several different ways
to define when one thing happens and the other. Okay, let's see some device function, again,
this vector function we had before, from brass, so if you kind of create the device function, which
looks essentially the same, there we hide the stream creation and the instruction in there,
and then we need to convert to device pointer, which assumes that it's there,
well, then we get this one, but there's a lot of things automatically built, or assumption built,
and it's much nicer to handle differently, and there's now the clear variant, two things, one is a
pentax, one can ask to add an inter-up object, so if we look at the function, when we have
now an inter-up object, so what, then we can directly get a streaming object, the other thing we
can do is adjust arcs, so we say take the device pointer, off that one and use it and that only works
in order to make it a bit more controlled by having it wrapped in a dispatch,
so only cause base function, and since devices, especially directly need to call on P, this
or put on P, this patch in front of it, or kind of feature, my example, I put device, but they're
much more, so essentially that's it on the inter-up feature, which kind of makes it easy to combine
some things, so somewhat the mice code with Fogman P code, or wrapping some things around,
the other thing, I want to say, and I see that I've much more time than I expected,
it's a sneak preview of some other way to reduce the overhead with Fogman P,
which becomes also interesting for competitively with cocos, because they move that way itself,
oh, MMP has a bit of disadvantage that it can be slow, especially for flowings, and carries
well, on one hand, a lot of external information like these control variables, or, for instance,
if you start a device section with power, the compiler then decides how much threats it
to be used there, but if you can go then in some function core, for instance, in this
per region, you have another pair, you might not really have any parallel threats left, or
the compiler has to reserve some, so there's, and you have also a lot of state information where you
can set some state, and then later it gets used like number of threats and so on, and everything
like that needs to be carried on, that makes things slow, and the other thing is also a little
thing sub built in, like, holistically how many threats you use, so it works pretty well, but it
can be quite slow, depends on the compiler, some manage to do very well, some somewhat,
to see a bit less so, but yeah, it's also going to be getting there, but we'll be never as fast as
this coulder and tip yet, and now I mean as language, so there are now ideas to have the full support
of writing something with different syntax, which was there, so the first step has been already made,
that I had so-called team private variables, which is in hip and kuda hanna and us got shared,
which can be used all both for static variables and at kernel launch time, so, from as a kernel
like a bit there, that's when I meant to have the size, in open mp, that already exists in open
p6, the group private, clause, which is for static variables, and then also the group private,
which is not yet in a real release, but in a particular report, and so it should be in 6.1 by
no member, and the other one, which is a bit more work on progress, hopefully also makes
until no member is the syntax where the number of blocks and threats, especially in a kernel launch,
there's the idea of the syntax on the right, where we specifies the essentially the same way,
so number of teams, and also number of threats where one has these free values there, and then
it's inside the team dimension and so on, but with these dimension syntax, instead of the full one,
one takes the full one, it's a number of teams would be automatic, calculated, but otherwise
one gets the index, like shown there, and the next part, which is probably next, that one, because
I haven't seen any work on this one, would be to disable features, which cause launch over
from, so it's kind of what's upcoming next, and, well, actually, this short tour of all these topics
done, and this is the side, give quick overview of my peer and offload support,
enter up, and also could like features, should make things accessible, but
here, for hyper-formance parts, where it's really hot coat, like the cooler hip part, and the
end-hop, both are a bit easier, and you are seeing the vendor lips, there's a bit longer version of
both of them, the end-hop one is actually a longer one off mine, there were one by someone else
in the super-humidly buff tops, shown under this link, and that's small, that's for my side,
I'll just give a small advertisement of an open-source embedded recipe, conference, my company runs
in May, if someone is interested in this model system, and not on the end-latch one, and I
don't know why, but that's it from my side, and I'm up for question,
and we should have eight minutes, questions.
That was the question about that before my peer makes easier to interact with the vendor lips,
and where one still needs to link them, yes, I mean the only thing you really safe is
if you have the initial one you have a cooler crate, seam, cooler best-spray, and doing all the
melodic memcopy and so on, and the melodic memcopy, of course, you only have the
cooler, I mean you already link those parts because of the runtime, so principle it would link
the same library for already the basic off-mount support, for the Blast one it's a set of
trustworthy places that essentially could as firm create and destroy, so you still need to link
explicitly the Blast library, and have these cool Blast create, plus flat stream, and so on,
as before, and the other one, I said it shouldn't be really changed because it's already there,
but maybe for since some parts are not done at linked time, you probably may need to specify the link
the library is where, although the compiler looks at the runtime, so the question was,
whether one can specify some information in that, for instance, the target region doesn't spawn
of more things, more threats and things like that, I think to a certain extent yes and no, I think
it's nothing really well specified that one says this one does now this one, and it's really
guaranteed, and it's used by the compilers, but of course open mp, I don't know, one was at five,
five, two, maybe five dot one, had this is assume, and it assumes, which I mean was a bit bad,
and there one can have of course saying no open mp contains, and so some principle could
wrap the inner block by having saying no open mp parallelism, I think it's called, so there's
some ways to do it, but I think it's not yet really fully utilized by the compilers, and
it's a certain extent also bit to wake what one needs to put directly to make sure that
the wanted feature is done, but in principle, one can do annotate things, but my feeling is a lot
of things, it's not too much used, the whole expression is definitely used by compilers, where
one says this expression is let's say always greater than zero, but with the others, I think this
port is much less, and a bit of the stage to the last talk,
I think it's a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a