-
Notifications
You must be signed in to change notification settings - Fork 5
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
Find a solution to compile-time block size parameter. #3
Comments
If one can find a good configurable and abstract way to express the third option, it is not to bad imho. |
As discussed offline with @tdd11235813, this will be left open on purpose. Possible solutions are mentioned above, but as the design of primitives is not finalized anyways, it is still not clear which is the best solution. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
By now, the block size is a template parameter of the reduce kernel to allow for dead code elimination and unrolling. Of course, this requires that it is known at compile time. But this is problematic for accelerators which have a block size that is device-dependent, like the CpuThreads. In theory (practically, this needs to be fixed anyways, see #1 ), in this case the number of cores would form a good block size, but this is dependent on the platform. Several solutions come to mind:
By now, I have not found a satisfying solution.
However, this can be delayed until #1 is resolved, because the thread-based cpu accelerators dont work as expected anyways by now.
Still, I guess this requires discussion, @tdd11235813
The text was updated successfully, but these errors were encountered: