Как производительность операций с массивами Python / Numpy масштабируется с увеличением размеров массива?

Как масштабируются массивы Python / Numpy с увеличением размеров массива?

Это основано на некотором поведении, которое я заметил при тестировании кода Python для этого вопроса: как выразить это сложное выражение с помощью кусочков

Проблема в основном заключалась в индексации для заполнения массива. Я обнаружил, что преимущества использования (не очень хороших) версий Cython и Numpy над циклом Python варьировались в зависимости от размера используемых массивов. И Numpy, и Cython испытывают растущее преимущество в производительности до некоторой степени (где-то около для Cython и для Numpy на моем ноутбуке), после чего их преимущества уменьшились (функция Cython осталась самой быстрой). $N=500$ $N=2000$

Это оборудование определено? С точки зрения работы с большими массивами, какие рекомендации следует придерживаться для кода, где оценивается производительность?

График времени выполнения относительно зацикленного кода для векторизованных и Cython-реализаций

Этот вопрос ( почему не мое матрично-векторное масштабирование умножения? ) Может быть связан, но мне интересно узнать больше о том, как различные способы обработки массивов в Python масштабируются относительно друг друга.

python performance numpy

— Нат Уилсон
источник

Вы пробовали Numexpr ? Там же, к примеру, этот разговор , который указывает на blosc и CArray , все это значит ускорить процесс дальнейшей (и , возможно , в обход ограничений пропускной способности памяти).

— 0 0

Можете ли вы опубликовать код, используемый для профиля. Здесь, вероятно, происходит несколько вещей.

— meawoppl

$4$ $16 kB$

def timeit(size):
     t0 = time.time()
     for _ in xrange(10):
         np.random.random(size)
     return time.time() - t0

sizes = np.logspace(1, 6, 40)
times = [timeit(s) for s in sizes]

В этом тесте есть несколько ошибок, для начала я не отключаю сборку мусора и беру сумму, не самое лучшее время, но терпите меня.

$8000$ $64 kB$

Стоит ли беспокоиться о размере кеша? Как правило, я говорю нет. Оптимизация для него в Python означает усложнение кода для сомнительного прироста производительности. Не забывайте, что объекты Python добавляют несколько накладных расходов, которые сложно отследить и предсказать. Я могу думать только о двух случаях, когда это является важным фактором:

Основные операции над большими массивами (например, оценка полинома), ограниченные пропускной способностью памяти. Используйте Numexpr или (если данные намного больше) Pytables . Они оптимизированы для учета размера кэша среди других оптимизаций.
Код, критичный к производительности: если вы хотите сжимать каждую микросекунду, вам не следует использовать Python в первую очередь. Написание векторизованного Cython и оставление компилятора делать то, что он делает лучше всего, - это, вероятно, безболезненный путь.

В комментариях Эверт упомянул CArray. Обратите внимание, что, даже работая, разработка остановилась и была заброшена как самостоятельный проект. Функциональность будет включена в Blaze вместо этого, в продолжающийся проект по созданию «Numpy нового поколения».

— Davidmh
источник