[suggestions] OpenMP task + OMPT

OpenMP 5.0 will be the next version of the OpenMP specification, which we expect will be officially released in 2018. TR4 can be viewed as an alpha release of OpenMP 5.0 This forum is for public discussion of the Technical Report.

[suggestions] OpenMP task + OMPT

Postby achalk » Mon May 22, 2017 6:27 am

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
ompt_record_task_create_s.codeptr_ra
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
for(...){
  for(...){
    #omp task .... name(pair)
    {
       pair_task(...);
    }
  }
  #omp task ... name(self)
  {
    self_task(...);
  }
}


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.
achalk
 
Posts: 9
Joined: Wed Sep 21, 2016 2:54 am

Return to TR4 OpenMP 5.0 Preview Discussion

Who is online

Users browsing this forum: No registered users and 1 guest

cron