passlab / homp Goto Github PK

For some applications, we can simply copy all the possible data to a device at once, and then perform distribution of loops for load balance. This should well for iterative loops (e.g. block matching) in that all data (the two images) will be read.

Even if there are data that will be written by the loop body, our runtime should keep record on which data region(map) is updated by each device and then they copy back all the written data to the host.

For some applications, we can simply copy all the possible data to a device at once, and then perform distribution of loops for load balance. This should well for iterative loops (e.g. block matching) in that all data (the two images) will be read.

Even if there are data that will be written by the loop body, our runtime should keep record on which data region(map) is updated by each device and then they copy back all the written data to the host.

It generates segmentation-fault code for the parallel region. use either nvcc (which use gcc 4.8.5 from the system) or explicitly use gcc-5.3.0

nvcc by default will use system gcc, which should be less than 4.9

In CUTOFF, when one dev is turned off for offloading, it does not involve in data exchange which requires inter-dev barrier operations, thus there is deadlock.

Not sure what is the easiest way to fix at this moment

For the following example, we will need to add a ratio (2) in the align policy to align array x to y
int y[n];
int x[2*n];

map(from:y distribute(BLOCK)) map(to: distribute(ALIGN(y, 2)))
for (i=0;i<n;i++) {
y[i] = x[2*i]
}

Currently, halo-region exchange will do copy of the halo region even in shared data maps, which is actually not needed. We should have the runtime to detect the kinds of maps are and decide whether a actually memcpy should be called or not. This could be done in omp_map_malloc and/or omp_halo_region_pull functions.

1. one time decision making of loop distribution: BLOCK and MODEL_AUTO
2. two times decision making of loop distribution: MODEL_PROFILE_AUTO, SCHED_PROFILE_AUTO.
   In these two policies, distribute a small amount of chunks first, profile it and then distribute the rest
3. Multiple times decision making of loop distribution: SCHED_DYNAMIC, SCHED_GUIDED

Currently we use a single map object to keep track of data that are distributed in those policies that need more than one decision making. One alternative is to create and use a new map each time we need to distribute data or loop.