A simple question about the handle

[krux02]

I know this is an issue tracker, and not really the right place to ask question, but I think I do it anyway.

With ttc_init I get a pointer to a ttc handler struct. Am I allowed to have several of them around, and is this behavior encouraged? Is it ok to have one struct in each module? Is it ok to have one instance per parameter? Or do I have to keep one single instance around and put it into some global variable?

[tongsucn]

@krux02 It is allowed to have multiple handlers. But using the same handler can help reuse existing transpose configurations. i.e. If you execute the same transpose (same size, perm, dim, datatype and loop_perm in ttc_param_s) for multiple times in one run, then only the first execution will actually call the ttc (python), and the rest of the callings will reuse the existing solution. So it's up to you!

To be noticed: Database support may be added to TTC-C in the future. Each handler will be related to one database, which means all the solutions within one database will share the same ttc_opt_s values. E.g. we can then store the solutions of CUDA and AVX512 separately and reuse them in future runs (without calling ttc again).

Do not hesitate to ask if you have more questions or advice.

[krux02]

Yes I had an idea, but it was kind of radical. My idea was to remove all handle parameters entirely, and make the handle state into a state of the library. This would simplify the API a lot but it's also as I said radical, and what you just suggested, having multiple databases would become a bit more dirty.

[krux02]

I also wonder if it might be a good idea, to split the compilation of the plan, and the execution into two different function.

static ttc_plan* plan = NULL;
if(plan == NULL) {
  ttc_param param = { [...] };
  plan = ttc_compile_transpose_plan(handle, param);
}
ttc_execute_plan(handle, plan, input, result);

This saves the overhead on the client side to create the param struct when it's not necessary anymore, and on the library side, there is no need anymore to do the lookup from the param to the plan every time the function is called.

It also allows the client to easily dispose plans that are not needed anymore, if there is a delete_plan function.

If there is a persistent database of transpositions, the ttc_compile_transpose_plan would be the only function that needs to access the database, there won't be a database access anymore as soon as the plan exists.