Я работаю над переписыванием модуля Python, изначально написанного на C, с использованием API Python-C для Cython. Модуль также использует NumPy. Основная задача проекта — поддерживать текущую скорость модуля, а также он должен работать для всех типов данных Numpy. Я думаю использовать объединенный тип данных, чтобы сделать его универсальным, но я беспокоюсь из-за его влияния на производительность. Есть ли какой-либо другой метод, который можно использовать вместо плавного типа, который я могу использовать для достижения как скорости, так и общего кода.
Альтернативы слитного типа в cython
comment
Меня беспокоит его негативное влияние на производительность. Вы измеряли это на самом деле? Можете ли вы привести конкретный пример?
- person ali_m schedule 25.03.2015
comment
@ali_m, это правда, что автоматическая диспетчеризация cython на основе типов предохранителей работает относительно медленно. В моих тестах диспетчеризация занимала ~1,5 микросекунды.
- person MrPisarik schedule 03.02.2021
Ответы (1)
Игнорируя совершенно правильный комментарий ali_m о том, действительно ли вы измерили свои проблемы с производительностью...
http://docs.cython.org/src/userguide/fusedtypes.html#selecting-specializations
«Для функции cdef или cpdef, вызываемой из Cython, это означает, что специализация определяется во время компиляции. Для функций def аргументы проверяются на тип во время выполнения, и для определения необходимой специализации применяется подход с максимальным усилием».
По сути, если вы звоните из Cython, проблем быть не должно — отдельные функции генерируются и используются без накладных расходов. Если вы звоните из Python, он, очевидно, должен остановиться и подумать, какой из них вызывать.
Но измерьте свою производительность, прежде чем беспокоиться об этом! (И прочитайте руководство, которое довольно четко отвечает на ваш вопрос.)
person
DavidW
schedule
25.03.2015
