-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A simple question about the handle #6
Comments
@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 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 Do not hesitate to ask if you have more questions or advice. |
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. |
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. |
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?The text was updated successfully, but these errors were encountered: