Почему numpy является 'медленным' отдельно?
Учитывая поток здесь
Кажется, что numpy не является самым идеальным для крайнего быстрого вычисления. Кто-либо знает то, о чем наверху мы должны знать при использовании numpy для числового вычисления?
3 ответа
Ну, это зависит от того, чем вы хотите заниматься. XOR, например, вряд ли актуален для кого-то, кто интересуется численной линейной алгеброй (для которой numpy довольно быстр благодаря использованию оптимизированных библиотек BLAS / LAPACK внизу).
Как правило, основная идея для получения хорошей производительности от numpy состоит в том, чтобы амортизировать стоимость интерпретатора по нескольким элементам за раз. Другими словами, переместите циклы из кода Python (медленно) в циклы C / Fortran где-нибудь в numpy / BLAS / LAPACK / etc. внутренние (быстро). Если вам удастся выполнить эту операцию (называемую векторизацией), производительность обычно будет достаточно хорошей.
Конечно, вы можете получить даже лучшую производительность, отказавшись от интерпретатора python и используя, скажем, C ++. Будет ли этот подход успешным или нет, зависит от того, насколько вы хороши в высокопроизводительном программировании на C ++ по сравнению с numpy, и от того, какую именно операцию вы пытаетесь выполнить.
Я не могу точно сказать, но предполагаю, что есть два фактора:
Возможно, numpy копирует больше вещей? weave часто выполняется быстрее, если вы избегаете выделения больших временных массивов, но здесь это не имеет значения.
numpy имеет небольшие накладные расходы, используемые при итерации по (возможно) многомерным массивам. Эти накладные расходы обычно затмеваются обработкой чисел, но xor действительно очень быстрый, поэтому все, что действительно имеет значение, - это накладные расходы.
Каждый раз, когда у вас есть выражение типа x = a * b + c / d + e , вы получаете один временный массив для a * b , один временный массив для c / d , один для одной из сумм и, наконец, одно распределение для результата. Это ограничение типов Python и перегрузки операторов. Однако вы можете делать что-то на месте явно, используя операторы расширенного присваивания ( * = , + = и т. Д.), И быть уверенным, что копии не будут созданы.
Что касается конкретной причины, по которой NumPy работает медленнее в этом тесте, трудно сказать, но, вероятно, это связано с постоянными накладными расходами на проверку размеров, маршалинг типов и т. Д., Которые Cython / etc. не о чем беспокоиться. Что касается более крупных проблем, вы, вероятно, увидите, что это становится ближе.