Closed weslleyspereira closed 1 year ago
This issue is related to https://github.com/tlapack/tlapack/pull/211
Mmmm, that's right, mixing the existing profiling and the codelet profiling could be inconvenient.
Perhaps after all we should rather add a STARPU_CODELET_PROFILING
environment variable. Adding the reading of the env variable can be done in _starpu_profiling_start
to set a new _starpu_codelet_profiling
global variable.
Thanks for this! I have extended it and added a test, will appear on github within a day, or you can pick it up from gitlab
This PR makes a minor change that prevents codelets from being modified inside (at least) some tasks, when profiling is disabled.
With this change, codelets could be implemented as static constant expressions. Right now, as I noticed in the StarPU examples, codelets need to be "global" non-const variables. By "global", I mean: "not associated to the local scope where the task is defined".
Global variables are bad for C++ template libraries. The reason: global variables cannot be on header files, they should be either on the application executable or inside the compiled library. In the current state of StarPU, we would need to dynamically allocate space for codelets if their creation depend on template arguments. Since codelets are not that small (704B) and since dynamic memory allocation can be expensive, I would like to avoid it.
In the future, users (me included) could need both (1) profiling and (2) codelets working as constant static expressions. In this case, maybe there is a way to disable only functions reading information from
per_worker_stats
, which currently arestarpu_codelet_display_stats()
andstarpu_bound_print_lp()
.