Dlaczego wydajność numpy nie skali

Question

Porównywałem względną skuteczność wyrażeń numpy i rozumowania w Pythonie pomnażając tablice liczb losowych. (Python 3.4/Spyder, Windows i Ubuntu).

Jak można się spodziewać, dla wszystkich, z wyjątkiem najmniejszych tablic, numpy szybko przewyższa zrozumienie listy, a dla zwiększenia długości macierzy uzyskano oczekiwaną krzywą sigmoidową dla wydajności. Ale sigmoid jest daleki od gładkości, co jest dla mnie zagadkowe.

Oczywiście istnieje pewna ilość szumu kwantyzacji dla krótszych długości tablic, ale pojawiają się nieoczekiwanie hałaśliwe wyniki, szczególnie w systemie Windows. Liczby są średnią z 100 przebiegów różnych długości tablic, więc powinny mieć wygładzone efekty przejściowe (tak bym pomyślał).

Numpy and Python list performance comparison 

Poniższe dane pokazują współczynnik mnożenia macierzy o różnych długościach korzystających numpy przeciwko listowego.

Array Length Windows  Ubuntu 
      1  0.2  0.4 
      2  2.0  0.6 
      5  1.0  0.5 
      10  3.0  1.0 
      20  0.3  0.8 
      50  3.5  1.9 
     100  3.5  1.9 
     200  10.0  3.0 
     500  4.6  6.0 
     1,000  13.6  6.9 
     2,000  9.2  8.2 
     5,000  14.6  10.4 
     10,000  12.1  11.1 
     20,000  12.9  11.6 
     50,000  13.4  11.4 
    100,000  13.4  12.0 
    200,000  12.8  12.4 
    500,000  13.0  12.3 
    1,000,000  13.3  12.4 
    2,000,000  13.6  12.0 
    5,000,000  13.6  11.9 

Więc myślę, że moje pytanie jest może ktoś wyjaśnić, dlaczego wyniki, szczególnie pod Windows są tak głośne. Przeprowadziłem testy wiele razy, ale wyniki zawsze wydają się być dokładnie takie same.

AKTUALIZACJA. W sugestii Reblochona Masque wyłączyłem zbieranie gadżetów. Który wygładza nieco wydajność systemu Windows, ale krzywe są nadal nierówne.

Numpy and Python list performance comparison 
(Updated to remove garbage collection) 

Array Length Windows  Ubuntu 
      1  0.1  0.3 
      2  0.6  0.4 
      5  0.3  0.4 
      10  0.5  0.5 
      20  0.6  0.5 
      50  0.8  0.7 
     100  1.6  1.1 
     200  1.3  1.7 
     500  3.7  3.2 
     1,000  3.9  4.8 
     2,000  6.5  6.6 
     5,000  11.5  9.2 
     10,000  10.8  10.7 
     20,000  12.1  11.4 
     50,000  13.3  12.4 
    100,000  13.5  12.6 
    200,000  12.8  12.6 
    500,000  12.9  12.3 
    1,000,000  13.3  12.3 
    2,000,000  13.6  12.0 
    5,000,000  13.6  11.8 

UPDATE

W @ sugestią Sida, mam ograniczone go działa na jednym rdzeniu na każdej maszynie. Krzywe są nieco bardziej płynne (szczególnie w systemie Linux), ale nadal mają fleksje i trochę szumu, szczególnie pod Windows.

(To było faktycznie przegięć, że był pierwotnie zamiar pisać o, jak pojawiają się one stale w tych samych miejscach.)

Numpy and Python list performance comparison 
(Garbage collection disabled and running on 1 CPU) 

Array Length Windows  Ubuntu 
      1  0.3  0.3 
      2  0.0  0.4 
      5  0.5  0.4 
      10  0.6  0.5 
      20  0.3  0.5 
      50  0.9  0.7 
     100  1.0  1.1 
     200  2.8  1.7 
     500  3.7  3.3 
     1,000  3.3  4.7 
     2,000  6.5  6.7 
     5,000  11.0  9.6 
     10,000  11.0  11.1 
     20,000  12.7  11.8 
     50,000  12.9  12.8 
    100,000  14.3  13.0 
    200,000  12.6  13.1 
    500,000  12.6  12.6 
    1,000,000  13.0  12.6 
    2,000,000  13.4  12.4 
    5,000,000  13.6  12.2 

Answer 1

Kolektor śmieci wyjaśnia większość niego. Resztę może stanowić fluktuacja w oparciu o inne programy uruchomione na twoim komputerze. Co powiesz na wyłączenie większości rzeczy i uruchomienie minimalnego minimum i przetestowanie go. Ponieważ korzystasz z datetime (który jest faktycznym czasem), musisz wziąć pod uwagę także wszelkie przełączniki kontekstu procesora.

Można również spróbować uruchomić ten proces, gdy jest on przymocowany do procesora za pomocą wywołania uniksowego, co może pomóc w jego wygładzeniu. Na Ubuntu można to zrobić stąd: https://askubuntu.com/a/483827

Dla procesora okna powinowactwa można ustawić w następujący sposób: http://www.addictivetips.com/windows-tips/how-to-set-processor-affinity-to-an-application-in-windows/

Answer 2

od moich opinii:

Zazwyczaj zbieranie śmieci wyjaśnia hałasu w testach wydajności bnchmark; możliwe jest wyłączenie go w celu przeprowadzenia testów, a w pewnych warunkach spowoduje wygładzenie wyników.

Oto link do tego, jak i dlaczego wyłączyć GC Why disable the garbage collector?

Poza GC, to zawsze jest trudne do uruchomienia benchmarków jak innych procesów uruchomionych w systemie może mieć wpływ na wydajność (połączeń sieciowych kopii zapasowych systemu, itp. ... które mogą być zautomatyzowane i cicho działające w tle); może mógłbyś spróbować ze świeżym startem systemu i jak mało innych procesów, jak to możliwe?