Як масштабується ефективність операцій масиву Python / Numpy зі збільшенням розмірів масиву?

Як масштабувати масиви Python / Numpy зі збільшенням розмірів масиву?

Це ґрунтується на деякій поведінці, яку я помітив під час тестування коду Python для цього питання: Як висловити цей складний вираз за допомогою nummy-фрагментів

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

Чи визначено це обладнання? Що стосується роботи з великими масивами, які найкращі практики слід дотримуватися для коду, де оцінюється продуктивність?

Графік часу виконання щодо певного коду для векторизованих та реалізацій Cython

Це питання ( чому мій масштабування множинних матриць-векторних масштабів? ) Може бути пов'язаним, але мені цікаво дізнатися більше про те, як різні способи обробки масивів у масштабі Python відносно один одного.

python performance numpy

— Нат Вілсон
джерело

Ви пробували numxpr ? Наприклад, є ця розмова, яка вказує на блокчейн і 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 нового покоління".

— Давидм
джерело