Question

我已经看过@ 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

Answer 1

某些）答案：我已经找到了一些我在这里提出的问题的答案

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?

ANSWWR：它似乎有一些错误和某些不完整的功能。该代码还建议API可能会更改。

但是，当可以使用时，这基本上是一个奇迹功能，可以轻松地将速度提高一个数量级（在中小型阵列上）。因此，即使记录了此Alpha版本也很好。

@ cupy.fuse cupy python装饰器在哪里记录？

1 个答案: