Objet : Developers list for StarPU
Archives de la liste
Re: [Starpu-devel] Problem with partitioning matrix with starpu_matrix_filter_block
Chronologique Discussions
- From: Samuel Thibault <samuel.thibault@inria.fr>
- To: Johan Mazel <johan.mazel@gmail.com>
- Cc: starpu-devel@lists.gforge.inria.fr
- Subject: Re: [Starpu-devel] Problem with partitioning matrix with starpu_matrix_filter_block
- Date: Thu, 9 Jan 2020 11:58:49 +0100
- List-archive: <http://lists.gforge.inria.fr/pipermail/starpu-devel/>
- List-id: "Developers list. For discussion of new features, code changes, etc." <starpu-devel.lists.gforge.inria.fr>
- Organization: I am not organized
Hello,
Johan Mazel, le mer. 08 janv. 2020 23:12:46 +0100, a ecrit:
> If I try to use starpu_matrix_filter_block (for example by decommenting
> line 51
> and 52 in test_starpu.c), I obtain the following results:
> * Worker 0 get values with index 0 -> 7.
The problem is not the partitioning: it is correct, as shown by
test_cpu: id (1804289383) ; nx: 2 ; ny: 4
The issue is in the data access in your test_cpu_func, you mustn't use
nx, but ld:
unsigned nx = STARPU_MATRIX_GET_NX(matrix_res);
unsigned ld = STARPU_MATRIX_GET_LD(matrix_res);
unsigned ny = STARPU_MATRIX_GET_NY(matrix_res);
for (j = 0; j < ny; j++) {
for (i = 0; i < nx; i++) {
printf("test_cpu: id (%u) ; res_m[%d,%d]: %lu\n", id, j, i, res_m[j*ld +
i]);
}
}
Since partitioning is done in-place, ld really mustn't be ignored (and
it shouldn't be ignored in the general case anyway, because you never
know when you would change your code in a way that makes taking ld into
account mandatory)
Samuel
- [Starpu-devel] Problem with partitioning matrix with starpu_matrix_filter_block, Johan Mazel, 08/01/2020
- Re: [Starpu-devel] Problem with partitioning matrix with starpu_matrix_filter_block, Samuel Thibault, 09/01/2020
- Re: [Starpu-devel] Problem with partitioning matrix with starpu_matrix_filter_block, Johan Mazel, 09/01/2020
- Re: [Starpu-devel] Problem with partitioning matrix with starpu_matrix_filter_block, Samuel Thibault, 09/01/2020
Archives gérées par MHonArc 2.6.19+.