Enable PaRSEC profiling system #227
Conversation
|
@devreal I added a @evaleev @robertjharrison What is our TT creation model? Do we want to authorize multithreaded TT creation? That needs to be protected (and that's not the only thing that will be fragile if multiple threads can create TTs, I believe). |
|
In MAD backend TT creation must be done from a single thread, I believe. |
|
I think the TT base classes common to both backends also have points where
this assumption is made.
I don't see a need for a single TTG to be composed in parallel, or even for
one process to be composing different TTGs in separate threads. We ideally
need to permit overlapping execution of multiple TTGs on the same world,
but the current ttg fence model would seem to fence all executing TTGs
rather than individual ones. But that is addressed by using multiple
worlds.
…On Fri, Mar 25, 2022 at 7:22 AM Eduard Valeyev ***@***.***> wrote:
In MAD backend TT creation must be done from a single thread, I believe.
—
Reply to this email directly, view it on GitHub
<#227 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABZSAPPWVOYASSC45WGY4ATVBWOYHANCNFSM5RTBJCSA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Robert J. Harrison
tel: 865-274-8544
|
| @@ -273,6 +282,21 @@ namespace ttg_parsec { | |||
| #endif // TTG_USE_USER_TERMDET | |||
| } | |||
|
|
|||
| template <typename keyT, typename output_terminalsT, typename derivedT, typename input_valueTs = ttg::typelist<>> | |||
| void register_new_tt(const TT<keyT, output_terminalsT, derivedT, input_valueTs> *t) { | |||
There was a problem hiding this comment.
I think it'd be sufficient to take TTBase* here since you only need the name.
| @@ -2206,6 +2240,10 @@ namespace ttg_parsec { | |||
| } | |||
| } | |||
|
|
|||
| static parsec_key_t make_key(const parsec_taskpool_t *tp, const parsec_assignment_t *as) { | |||
There was a problem hiding this comment.
I'm trying to understand what make_key does... parsec_assignment_t is a struct with one integer member. How is it safe to cast it to a uintptr_t below?
There was a problem hiding this comment.
self.locals is an array of assignment_t with more than 4 of them, so there is room in self.locals to store the pointer-size int. Not clean, but I'm abusing the only space I have to store stack information.
| @@ -161,7 +164,12 @@ namespace ttg_parsec { | |||
|
|
|||
| public: | |||
| static constexpr const int PARSEC_TTG_MAX_AM_SIZE = 1024 * 1024; | |||
| WorldImpl(int *argc, char **argv[], int ncores) : WorldImplBase(query_comm_size(), query_comm_rank()) { | |||
| WorldImpl(int *argc, char **argv[], int ncores) : WorldImplBase(query_comm_size(), query_comm_rank()) | |||
| #if defined(PARSEC_PROF_TRACE) | |||
There was a problem hiding this comment.
I would make that initialization independent of PARSEC_PROF_TRACE but make it an assignment here https://github.com/TESSEorg/ttg/pull/227/files#diff-b16b2b248d6db2366353f63da94be820a8905343d7452acc0639ffcaf3100068R330
|
Stale code superseded by PR #222 |
In order to have a working profiling system, the parsec_task_class
of each new TT needs to allocate 2 integers in an array that belongs
to the parsec_taskpool_t. Then, the profiling assumes that the
task class can compute an identifier that helps matching the end
of a task with the beginning, when those do not happen on the same
thread (e.g. for GPU or asynchronous execution). A few more fields
are used by the profiling system that need to be set.