Understanding execution order

Understanding execution order

Аватар пользователя Nicolas

The program I am looking at is supposed to perform load balancing of a 2-D pipeline parallel loop of tasks.
Imagine a 2-D (i=0...9, j=0...9) grid of 100 tasks
A task (i,j) is ready when task (i-1, j) and (i, j-1) are executed.
Tasks for which i-1 < 0 or j-1 < 0 are ready from the start (the environment provides the proper tags and data)

Since a step can only be prescribed by 1 tag collection I thought I would rely on data to help synchronize my computations step.

I have a problem with the execution order of tasks, I reduced my problem to the following simple case.

// Input from the environment
env -> [A],[B],;

// Steps Prescription
:: (tag_compute);
:: (problem_compute);

// Steps Execution
(tag_compute) -> ;
(problem_compute) -> [A],[B];
[A],[B] -> (problem_compute);

Basically, the control tag collection enumerates the diagonal wavefronts, each task produces data for its (i+1, j) and (i, j+1) neighbors.

Since I am having ordering issues I do not understand yet I did the following experiment:
remove all the data puts from the environment and the (problem_compute) steps.

I only generate the control tag for task (0,0)

My expectation was that all (tag_compute) steps would execute but none of the (problem_compute) (since I voluntarely starve the production of data).

Instead, all steps get executed.

Was I wrong to assume missing data would block the (problem_compute) steps ?

Also, if I understand properly, the way multiple prescribing tags is implemented in practice is to perform cascading tags (like in the cholesky example).
Is the intuition of using 1 tag + data reasonable or should I just stick on doing it the cholesky way ?

Thanks !

4 posts / 0 новое
Последнее сообщение
Пожалуйста, обратитесь к странице Уведомление об оптимизации для более подробной информации относительно производительности и оптимизации в программных продуктах компании Intel.
Аватар пользователя Nicolas

My problem seems to be coming from my using C++ pointer to objects as tags.
In a simpler repro using only integers I get the expected behavior.

My using objects came from a hack I made to print the tags to simulate the "trace" that I could not evaluate.
I wanted an object with a << operator with a vector member for storing the tag itself.
Unfortunately using an object triggered a static_cast error in
../../include/cnc/internal/cnc_tag_hash_compare.h: return static_cast< size_t >( x ) * 2654435761;

and so I used a pointer to this object.

I just realized reading Kath's presentation at CERN that I was not supposed to do that.

I will revert back to using a regular vector as my tag

Аватар пользователя Nicolas

The remaining problem comes from a misconception on how steps are invocated and when they wait for their input.

My original intuition was that the runtime monitored the data items consumed by a step and only when they are all there would the runtime call the step::execute method.

In practice, what seems to happen is that step::execute can be started when its control tag is available.
Then, the context.A.get method inside step::execute does not finds the data and the step is put to sleep.

My dumping information was printed before all the gets of the step were performed and it gave the wrong imporession that the step was executed.

Аватар пользователя Chih-ping Chen (Intel)
Quoting Nicolas
In practice, what seems to happen is that step::execute can be started when its control tag is available.
Then, the context.A.get method inside step::execute does not finds the data and the step is put to sleep.

Yes, you are correct about the behavior of ::execute. A step is re-queued when a data get fails, and gets executed from the very beginning when it is re-started.

Great to see that you have figured out allyour issues.

Зарегистрируйтесь, чтобы оставить комментарий.