Find a solution to compile-time block size parameter.

[DerWaldschrat]

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:

• Calculate/provide the number of threads at compile time. I dont know if this is possible, but this has the problem of cross-compilation and portability.
• Make blocksize a runtime parameter. This would probably require the kernel to be adjusted for optimal performance in the case of blockSize = 1.
• Introduce a switch-statement like solution which allows for runtime computations against several compile-time reduce kernels with different block sizes. This is ugly, bloats the code size and unflexible if new architectures evolve.

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

[ax3l]

If one can find a good configurable and abstract way to express the third option, it is not to bad imho.

[DerWaldschrat]

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.