Sandra Loosemore wrote:
On 7/21/26 05:53, Tobias Burnus wrote:
-fopenmp-ompt
-fopenmp-ompt=none
-fopenmp-ompt=basic
-fopenmp-ompt=enhanced // detailed, extended
Specify whether additional calls into the OpenMP runtime are generated
to improve tracing results with tools using the OMPT interface at the
expense of additional runtime overhead. However, OMPT is also supported
without this option.
With -fopenmp-ompt=none, no additional calls are generated.
My confusion about this option is: additional to *what*?
To what GCC generated by default for -fopenmp as required by the semantic.
For every call into the runtime, GCC can invoke a registered OMPT
callback - and in most cases, a call into the runtime is already there.
In a very few cases, the compiler-generated code can do either without a
call into the runtime or only has one at the beginning of a block of
user code (beginning of a region) – and not also at the end.
That's perfectly fine, except that for tracing with OMPT, the additional
data could be helpful. – See below for an example what -fopenmp-ompt
does and when it might help with actual code.
* * *
Thus, 'additional' refers to additionally to what always generated for
OpenMP code (i.e. with the bare -fopenmp).
BTW: Between the lines, the current documentation implies: If the
construct you are interested is not listed here, it is already handled
by -fopenmp itself. [Which is mostly true.]
* * *
Talking about additional runtime overhead makes it sound like it's an
internal implementation detail and I don't think users are supposed to
have to know what what features do or don't involve "additional" overhead.
It _is_ an implementation detail. It is only for users that care about OMPT -
and they
need to decide between better OMPT data vs. slower program.
And the documentation explicitly states for which constructs what additional
data can
be produced - and contains a reminder that this does not come for free, esp.
not the
'detailed' option.
NOTE: When tracing huge programs, users need to be pretty much aware what they
want to
trace. This might involve turning on the tracing only for certain blocks of
code or only
for specific events. - Tracing can make a program easily 10× slower and produce
tens of
gigabytes of tracing data very quickly, even when already strictly limiting
what one
tries to trace.
For small program: Just enabling everything with OMPT when using OMPT and
disabling it
("overhead") otherwise works as well. In that case, a user doesn't need to know
all
the glory details.
* * *
So could we talk about what features are supported at each level
first, and secondarily mention that the features at lower levels have
less runtime overhead than those at higher levels? Otherwise it seems
like the tail is trying to wag the dog.
But that's more or less what we do:
Using -fopenmp-ompt=basic, or just -fopenmp-ompt,
(feature level)
the runtime is called on region entry and exit instead
of only on region entry
(namely, what feature is additionally provides)
for the single, masked, and master constructs and with
static scheduling for the distribute and worksharing loop constructs.
(additional data: list of what constructs are exactly affected by this.)
But somewhere we need to tell the user what this flag does in general:
Specify whether additional calls into the OpenMP runtime are generated
to improve tracing results with tools using the OMPT interface
Namely: This is about OMPT – using this feature improves the tracing
And there are two notes related to "additional calls into the runtime":
(A) it has the downside that additional calls come
at the expense of additional runtime overhead.
i.e. they make the program slower - and
(B)
However, OMPT is also supported without this option.
is there to make clear: OMPT also works without that option,
even if the tracing with OMPT is nicer with the optiona that follow.
* * *
I am sure that it can be worded better – but I still have to see any proposal
on how to improve this.
Any suggestion?
Tobias
-----------------------------
PS: Example for -fopenmp-detail, in case it helps:
#pragma omp parallel // start multiple threads
{
... // some work by all threads
#omp masked filter(my_thread)
{
// some work only done by thread my_thread
}
... // more work done by all threads
}
The masked construct is turned into:
if (GOMP_has_masked_thread_num (my_thread))
{
...
}
And the runtime issues (if a callback is registered) for this:
anompt_callback_masked with scope 'encountered' (scope_begin_end) and some
additional data. Thus, the tracing tool could record: For Thread
my_thread: * 0 to 2500 ms - some work
* at 2500 ms - masked event encountered
* 2500 ms to 10000 ms some work
While with -fopenmp-ompt, this is changed; namely,
a slightly different function is called ('_with_end')
and an additional function ('masked_end'):
if (GOMP_has_masked_thread_num_with_end (my_thread))
{
...
GOMP_masked_end ();
}
which permits the tracing:
* 0 to 2500 ms - some work
* at 2500 ms - masked 'begin' event
* some work
* at 2650 ms - masked 'end' event
* 2650 ms to 1000 ms some work
Thus with -fopenmp-ompt, the tool and, hence, the user knows that the
work done between t = 2500 ms and t' = 2650 ms happend in a 'masked'
region.
In many cases, a user does not care. However, if my_thread takes 25 %
longer than the other threads, those 127 threads will be idle for
2500 ms which is generally a bad idea - wasting 2.5 s × 127 theeads =
5½ CPU minutes on waiting just for a single thread instead of running
shorter or using making use of that compute power for something else.
That's a lot - hence, a user might want to investigate way - and an
obvious candidate is the 'masked' region as that contains code only
executed by my_thread.
Well, with -fopenmp, the user just sees a 'masked' region - which does
not help for this purpose. It is sufficient to see that my_thread takes
10000 ms - and that the other threads need about 7500 milliseconds
plus that there is 'masked' region.
With -fopenmp-ompt, the user sees that my_thread spends there
150 ms - but that's only 1.5 % of the total runtime - or 6 % of the time
that my_thread takes longer.
Thus, the user has to search elsewhere why my_thread takes 25 % longer
than the other threads.
That would be real-world scenario for the usage of OMPT - both for what
OMPT with -fopenmp already gives -and when -fopenmp-opmpt on top helps.
* * *
Maybe that helps you to understand the feature - and, hence,
helps you to come up with a better wording :-)
