Page 1 of 1

[suggestions] OpenMP task + OMPT

Posted: Mon May 22, 2017 6:27 am
by achalk
Naming task regions:

With the new OMPT interface with OpenMP, it should be possible to develop tools to visualise the computation according to what thread is doing what work (which can be identified from things like the

Code: Select all

for tasks for example). It may be useful for the developer of a code to name task regions, so the output visualisation can specifically say what work is being done in each colour of the visualisation.

For example:

Code: Select all

    #omp task .... name(pair)
  #omp task ... name(self)
If OMPT is enabled when reaching the task pragma, the name is passed as an additional argument to ompt_callback_task_create_t (and/or stored in the trace record). This allows the programmer to use tools to find out exactly what is being executed when.

Question on ompt_callback_schedule_task_t:
So my understanding of the ompt_callback_schedule_task_t is as follows (or at least, a subset of its behaviour with explicit tasks):

thread X completes executing task with task_data A
thread X calls the task scheduler to find a new task to execute with task_data B
thread X calls the ompt_callback_schedule_task_t (if enabled) with prior_task_data=A, prior_task_status=ompt_task_complete and next_task_data=B
thread executes the task with task_data B

If no task is available immediately (due to dependencies or some other reason), rather than the above behaviour will the task framework instead:

thread X finds no new task
thread X calls the ompt_callback_schedule_task_t with prior_task_data=A, prior_task_status=ompt_task_complete and next_task_data=NULL

and then wait to find a new task? If creating a timeline visualisation (for example) having a task appear to take much longer than accurate will not be good.
If this is the case, then having seperate callbacks on task_schedule and task_unschedule (i.e. cancel, yield, complete) may be useful in generating more accurate displays of behaviours.