Re: [Starpu-devel] [LU factorisation: gdb debug output]

[Maxim Abalenkov <maxim.abalenkov@gmail.com>]

Dear Samuel,

I hope all is well with you. May I please ask you about the status of the Parallel Tasks in the current version of StarPU:

  http://starpu.gforge.inria.fr/doc/html/TasksInStarPU.html#ParallelTasks

  http://starpu.gforge.inria.fr/doc/html/TasksInStarPU.html#SPMD-modeParallelTasks

I have been thinking to use them in order to “imitate” subtasks and parallelise LU panel factorisation. Your opinion would be greatly appreciated. Thank you.

—

Best wishes,

Maxim

Maxim Abalenkov \\ maxim.abalenkov@gmail.com
+44 7 486 486 505 \\ http://mabalenk.gitlab.io

On 15 Jan 2018, at 18:04, Maxim Abalenkov <maxim.abalenkov@gmail.com> wrote:

Dear Samuel,

I have a very simple question. What is the overhead of using the STARPU_NONE access mode for some handles in the STARPU_DATA_MODE_ARRAY? In order to avoid using complicated offsets in my computation routines I would like to pass them a column of matrix tiles, while setting the “unused” tiles to “STARPU_NONE”. Would that create a correct DAG? Thank you and have a good evening!

—

Best wishes,

Maxim

Maxim Abalenkov \\ maxim.abalenkov@gmail.com
+44 7 486 486 505 \\ http://mabalenk.gitlab.io

On 10 Jan 2018, at 11:37, Maxim Abalenkov <maxim.abalenkov@gmail.com> wrote:

Dear Samuel et al.,

Thank you for your email. The problem I have at hand is a panel-wise LU factorisation. Where a panel is a column of matrix tiles and a tile denotes a block of a matrix. As a first implementation of LU factorisation I have built my algorithm around panels, where each panel gets processed by one StarPU task. Panel is a purely abstract notion. I call it a “container panel”, since it contains matrix tiles and makes working out data dependencies easier. To create these container panels I use StarPU’s concept of DATA_MODE_ARRAYs. Hence, the basic building block to resolve data dependencies "in the eyes" of StarPU is a panel. The algorithm works, but the performance is low.

Now, I would like to exploit the parallelism remaining in each container panel. I would like to operate by means of “subtasks”, where each subtask will work on a tile(s) of a panel. Would it be possible with “bubbles” that you mentioned earlier? Thank you and have a good day ahead!

—

Best wishes,

Maxim

Maxim Abalenkov \\ maxim.abalenkov@gmail.com
+44 7 486 486 505 \\ http://mabalenk.gitlab.io

On 8 Jan 2018, at 16:12, Samuel Thibault <samuel.thibault@inria.fr> wrote:

Hello,

Maxim Abalenkov, on mer. 03 janv. 2018 20:03:10 +0100, wrote:

a) What is the purpose of enforcing task execution on the home node? Is it
always necessary, when I use the STARPU_DATA_MODE_ARRAY in
“starpu_task_insert"? Please consider the code snippet I took from the
“fmultiple_manual.c”:

   // Enforce task execution on home node (STARPU_MAIN_RAM)
   core_starpu_codelet_zgetrf_pnl.specific_nodes = 1;

   for (int i = 0; i < STARPU_NMAXBUFS; i++) {
       core_starpu_codelet_zgetrf_pnl.nodes[i] = STARPU_MAIN_RAM;
   }

See the comment in the corresponding codelet function:

       /* This doesn't need to do anything, it's simply used to make coherency
        * between the two views, by simply running on the home node of the
        * data, thus getting back all data pieces there.  */

It's just a matter of collecting all pieces together on the same memory
node.

b) Can you please direct me to an example(s) of using StarPU subtasks (tasks
submitted by other tasks)?

I have to say I don't remember such kind of example. The problem is
that doing this kind of thing raises a lot of issues. Notably, if you
keep the default sequential consistency on data, the subtasks will
automatically be made to depend on the last submitted tasks which work
on the same data. I guess that's not what you want. Perhaps Terry and
Nathalie will have better answers with the addition of the notion of
bubble. At any rate, we need to know much better what exact semantic you
want from your subtasks, to determine what could suit your needs.

Samuel