Update kernel models

The simgrid kernel models provided in the repository have been generated with the matrix interface from StarPU. Since then, the CHAM_tile_t interface has been introduced and the hash is not computed with the same parameters. Thus, they should be updated with the new hash. @fpruvost can youplease take care of it ? Thanks.

changed milestone to %Chameleon 1.2.0

added Bug SimGrid labels

assigned to @fpruvost

Aaaah, I found why.

uint32_t _starpu_compute_data_footprint(starpu_data_handle_t handle)
{
	uint32_t interfaceid = (uint32_t)starpu_data_get_interface_id(handle);

	STARPU_ASSERT(handle->ops->footprint);

	uint32_t handle_footprint = handle->ops->footprint(handle);

	return starpu_hash_crc32c_be(handle_footprint, interfaceid);
}

We include the interfaceid in the footprint... This is so since essentially the beginning.

Actually this can't really work with dynamic interfaces, for which the interfaceid change vary. I have pushed fef1a70d945080922ad8cc4ff0e351a052889534 ("Fix footprint variability with registered interfaces") in starpu to make it use 0 instead of interfaceid for dynamic interfaces.

We're kind of stuck with having to update the footprints anyway, since we can't make the chameleon tile interface use the matrix interfaceid.

This would mean duplicating the perfmodel for the matrix-interface case and the tile-interface case :/

This would mean duplicating the perfmodel for the matrix-interface case and the tile-interface case :/

Aaah, no, actually STARPU_MATRIX_INTERFACE_ID happens to be 0, so using 0 instead of interfaceid for dynamic interfaces should actually be reverting to the matrix-interface footprint computation.

Is it a good thing ? even if it fixes our issue :)

It shouldn't be harmful. I guess cedric included the interfaceid just to be cautious, but we shouldn't be mixing footprint across interfaces anyway, so it should be fine.

In the end, with the latest master I believe there is nothing left to be done on the chameleon side, I checked with spotrf:

c521d83a	6400           	0.000000e+00   	1.134600e+01   	0.000000e+00   	1.134600e+01   	1.287317e+02   	1

versus cholesky_implicit's chol_model_potrf:

c521d83a	6400           	2.214000e+04   	0.000000e+00   	0.000000e+00   	0.000000e+00   	0.000000e+00   	0

The splrnt.sirocco-v100 file shows that the splrnt kernel was indeed never calibrated on sirocco-v100 for that tile size, only for sizes 6400 and 10240000.

Could it be that splgsy.sirocco-v100 was created with the problematic starpu master, and thus contains the erroneous footprint? The footprint for the 1600 tile size (10240000 bytes) really is a13597be.

(and then in such cases it's the files which would need fixing with a sed run)

mentioned in merge request !370 (closed)

mentioned in commit a9db19a2

closed

closed with commit 47e3a8ba