Jak skaluje się wydajność operacji tablicowych Python / Numpy wraz ze wzrostem wymiarów tablicy?

Jak skalują się tablice Python / Numpy wraz ze wzrostem wymiarów tablicy?

Jest to oparte na niektórych zachowaniach, które zauważyłem podczas testowania kodu Python dla tego pytania: Jak wyrazić to skomplikowane wyrażenie za pomocą numpy

Problem polegał głównie na indeksowaniu w celu zapełnienia tablicy. Odkryłem, że zalety używania (niezbyt dobrych) wersji Cython i Numpy w stosunku do pętli Pythona różniły się w zależności od wielkości zaangażowanych tablic. Zarówno Numpy, jak i Cython do pewnego stopnia zwiększają przewagę wydajności (gdzieś w okolicach dla Cython i dla Numpy na moim laptopie), po czym ich zalety spadły (funkcja Cython pozostała najszybsza). $N=500$ $N=2000$

Czy ten sprzęt jest zdefiniowany? Jeśli chodzi o pracę z dużymi tablicami, jakie są najlepsze praktyki, które należy stosować w przypadku kodu, w którym wydajność jest doceniana?

Wykres czasu wykonania względem zapętlonego kodu dla wektoryzacji i implementacji Cython

To pytanie ( dlaczego moje skalowanie mnożenia wektorów macierzy? ) Może być powiązane, ale interesuje mnie wiedza na temat różnych sposobów traktowania tablic w skali Pythona względem siebie.

python performance numpy

— Nat Wilson
źródło

Próbowałeś numexpr ? Jest też, na przykład, ta rozmowa, która wskazuje na blosc i CArray , wszystkie mające na celu przyspieszenie rzeczy (i być może ominięcie ograniczeń przepustowości pamięci).

— 0 0

Czy możesz opublikować kod użyty do profilowania? Prawdopodobnie dzieje się tutaj kilka rzeczy.

— 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]

Jest kilka rzeczy nie tak z tym testem, na początek nie wyłączam zbierania śmieci i biorę sumę, nie najlepszy czas, ale trzymaj się mnie.

$8000$ $64 kB$ , czyli wielkość pamięci podręcznej L1 i5 (Mój komputer).

Czy należy się martwić o rozmiar pamięci podręcznej? Zasadniczo mówię „nie”. Zoptymalizowanie go w Pythonie oznacza, że kod jest znacznie bardziej skomplikowany, co daje wątpliwy wzrost wydajności. Nie zapominaj, że obiekty Python dodają kilka kosztów ogólnych, które są trudne do śledzenia i przewidywania. Mogę myśleć tylko o dwóch przypadkach, w których jest to istotny czynnik:

Podstawowe operacje na dużych tablicach (takie jak ocena wielomianu), ograniczone przepustowością pamięci. Użyj Numexpr lub (jeśli dane są znacznie większe) Pytable . Są one zoptymalizowane pod kątem wielkości pamięci podręcznej i innych optymalizacji.
Kod krytyczny dla wydajności: jeśli chcesz wyciskać każdą mikrosekundę, nie powinieneś używać Pythona. Pisanie wektoryzowanego Cython i pozostawienie kompilatora robienia tego, co robi najlepiej, jest prawdopodobnie bezbolesną drogą.

W komentarzach Evert wspomniał o CArray. Zauważ, że nawet działający rozwój został zatrzymany i został porzucony jako samodzielny projekt. Funkcjonalność zostanie włączona do Blaze , trwającego projektu stworzenia „Numpy nowej generacji”.

— Davidmh
źródło