我看过@ cupy.fuse的一些演示，这无疑是使用Numpy语法进行GPU编程的奇迹。 cupy的主要问题在于，每个操作（如添加）都是完整的内核启动，然后是无内核的。因此，例如一系列的加法和乘法会付出很多内核痛苦。 （
这就是为什么使用numba @jit可能会更好的原因）
@ cupy.fuse（）似乎通过将函数内部的所有操作合并到单个内核中来解决此问题，从而显着降低了启动和免费成本。
但是除了演示和cupy.fusion类的源代码之外，我找不到其他任何文档。
我的问题包括：
cupy.fuse会积极地内联应用装饰器的函数内部调用的任何python函数，从而将它们滚动到同一内核中吗？
此增强日志暗示了这一点，但没有说明组成的函数是在同一内核中，还是仅在对被调用函数进行修饰时才允许使用。
https://github.com/cupy/cupy/pull/1350
如果是这样，我是否需要使用@fuse装饰这些功能。我在想这可能会损害内联，但对它没有帮助，因为它可能会将这些函数呈现为不可融合的（可能是非python）形式。
如果没有，我可以通过先用@ numba.jit装饰函数，然后再用@fuse装饰来获得自动内联。还是再次@jit以非融合形式呈现生成的python？
什么会破坏@fuse？有什么陷阱？是@fuse实验性的，不太可能保持？
参考资料：
https://gist.github.com/unnonouno/877f314870d1e3a2f3f45d84de78d56c
https://www.slideshare.net/pfi/automatically-fusing-functions-on-cupy
https://github.com/cupy/cupy/blob/master/cupy/core/fusion.py
https://docs-cupy.chainer.org/en/stable/overview.html
https://github.com/cupy/cupy/blob/master/cupy/manipulation/tiling.py
最佳答案
回答：我已经找到了一些我在这里提出的问题的答案
questions:
1. fusing kernels is such a huge advance I don't understand when I would ever not want to use @fuse. isn't it always better? When is it a bad idea?
答：保险丝尚不支持许多有用的操作。例如，z = cupy.empy_like（x）不起作用，也不能引用全局变量。因此，它根本无法普遍应用。
I'm wondering about it's composability
1. will @fuse inline the functions it finds within the decorated function?
答：查看时序和nvvm标记，看起来确实可以拉入子例程并将它们融合到内核中。因此，将事物划分为子例程而不是单片代码可以使用保险丝。
2. I see that a bug fix in the release notes says that it can now handle calling other functions decorated with @fuse. But this does not say if their kernels are fused or remain separate.
解答：查看NVVM输出，看来它们已合并。很难说有一些剩余开销，但是时序并未显示出表明两个单独内核的显着开销。关键是它现在可以工作了。从cupy 4.1开始，您不能从融合函数调用融合函数，因为返回类型错误。但是从5.1开始就可以。但是，您不需要装饰这些功能。无论您是否做，它都可以工作。
4. Why isn't it documented?
回答：它似乎有一些错误和一些不完整的功能。该代码还建议API可能会更改。
但是，当可以使用它时，这基本上是一个奇迹功能，可以在中小型阵列上轻松地将速度提高一个数量级。因此，即使记录了此Alpha版本，也很好。
关于python - @ cupy.fuse cupy python装饰器在哪里记录？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/53639723/