2016-04-05 14 views
9

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).Dlaczego wydajność numpy nie skali

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ł).

Performance characteristic

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.

Updated performance characteristic without garbage collection

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 

enter image description here

+0

Zbieranie śmieci? Może mógłbyś go wyłączyć, żeby przeprowadzić testy? –

+0

tutaj: http://stackoverflow.com/questions/20495946/why-disable-the-garbage-collector –

+1

@ReblochonMasque Dzięki za to. Poprawiło to płynność krzywej, chociaż nadal występuje pewien hałas. Nadal dostaję odmiany na krzywej nawet dla wysokich wartości n, które, jak sądzę, są po prostu szumem ... – TimGJ

Odpowiedz

3

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/

+0

Większość rzeczy jest wyłączona - właśnie uruchomiłem test i zostawiłem oba systemy na swoich własnych urządzeniach. Nie ma w tym nic wielkiego, co by tłumaczyło tak znaczące (i spójne) rozbieżności AFAIK, ale powoduje to coś podejrzanego. – TimGJ

+0

Czy możesz spróbować przypiąć program do jednego procesora/Core i zobaczyć, jak to taryfa? To powinno być łatwe do zrobienia w Ubuntu: http: //askubuntu.com/a/483827 – Sid

+0

Wielkie dzięki za sugestię. Wdrożenie Linuksa polega na względnie płynnym skalowaniu, aczkolwiek z kilkoma nieoczekiwanymi odmiennościami. Spróbuję tego pojedynczego elementu, ale nie wiem, czy jest to możliwe w systemie Windows, gdzie wydajność jest znacznie bardziej zła. – TimGJ

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?

Powiązane problemy