Где задокументирован @ cupy.fuse cupy python decorator?

Question

Я видел некоторые демонстрации @ cupy.fuse, которые являются не чем иным, как чудом для программирования на GPU с использованием синтаксиса Numpy.Основная проблема с Cupy состоит в том, что каждая операция, такая как добавление, является полным запуском ядра, а затем свободным от ядра.Так, например, серия складываний и умножений платит большую боль в ядре.(Вот почему лучше использовать numba @jit)

@cupy.fuse (), кажется, исправляет это, объединяя все операции внутри функции с одним ядром, создавая резкое снижение запуска ибесплатные расходы.

Но я не могу найти никакой документации по этому вопросу, кроме демонстраций и исходного кода для класса cupy.fusion.

У меня есть следующие вопросы:

1. Будет ли cupy.fuse агрессивно встроить какие-либо функции Python, вызываемые внутри функции, к которой применяется декоратор, и, таким образом, свернуть их в одно и то же ядро?

этот журнал улучшений намекает на это, но не говорит, составлен ли онфункции находятся в том же ядре или просто разрешены, когда вызываемые функции также оформлены.https://github.com/cupy/cupy/pull/1350

Если это так, нужно ли мне украшать эти функции с помощью @fuse.Я думаю, что это может помешать встраиванию, а не помочь ему, поскольку это может привести к переводу этих функций в не плавкую (возможно, не python) форму.

Если нет, могу ли я получитьавтоматическое встраивание, сначала декорируя функцию с помощью @ numba.jit, а затем декорируя с помощью @fuse.Или снова @jit отобразит полученный питон в не плавкой форме?

Что ломает @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 / ru / 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?

ОТВЕТ: Похоже, что в нем есть некоторые ошибки и некоторые неполные функциональные возможности.Код также рекомендует API, поскольку он может быть изменен.

Однако это, по сути, чудодейственная функция, когда ее можно использовать, легко увеличивая скорость на порядок на массивах малого и среднего размера.Так что было бы неплохо, если бы даже эта альфа-версия была задокументирована.