# OpenCL Backend: Broadcast/Reduce Ops **URL:** https://dev-discuss.pytorch.org/t/opencl-backend-broadcast-reduce-ops/395 **Category:** hardware-backends **Created:** [November 4, 2021, 10:23pm UTC](https://dev-discuss.pytorch.org/t/opencl-backend-broadcast-reduce-ops/395 "2021-11-04T22:23:49Z") **Posts on this page:** 1 **Showing post:** 3
### Author: ![artyom-beilis](https://yyz2.discourse-cdn.com/flex036/user_avatar/dev-discuss.pytorch.org/artyom-beilis/32/207_2.png) [@artyom-beilis](https://dev-discuss.pytorch.org/u/artyom-beilis) #### Post date: [November 5, 2021, 2:30pm UTC](https://dev-discuss.pytorch.org/t/opencl-backend-broadcast-reduce-ops/395/3 "2021-11-05T14:30:04Z")
Yes I’ve seen it. But there is a small but critical difference. Unlike cuda or CPU code that is compiled in-advance using templates, the OpenCL code is generated and compiled on demand. Which makes it simpler to maintain. It is relevant to this discussion: > [@CUDA loops case study: code generation vs templates](https://dev-discuss.pytorch.org/t/cuda-loops-case-study-code-generation-vs-templates/302): > > CUDA loops case study: code generation vs templates Problem statement It’s not easy defining a pointwise operation in CUDA for TensorIterator. Because we are ahead-of-time compiling a set of kernels that must work universally for all combinations of dtypes/scalar combinations (in this Quip, I ignore the actual iteration aspects of TensorIterator), there is quite a bit of work you have to do: When defining any particular kernel, you must statically know both what the stored in memory type (sc… --- _[View the full topic](https://dev-discuss.pytorch.org/t/opencl-backend-broadcast-reduce-ops/395)._