Dlaczego 16 wątków jest wydajniejszych niż 8 na i7 z 4-rdzeniowymi hiperwątkami? (Robocopy)


3

W systemie Windows 8.1 używam Robocopy do zapisywania danych 2 serwerów w miejscu do przechowywania na dedykowanym komputerze. Wolumin danych to 147 314 plików w 4110 folderach (66 841 885 760 bajtów).

Wszystkie 3 zaangażowane komputery wyposażone są w procesor i7 z 4 rdzeniami i są w sieci 1 Gb. Miejsce do przechowywania celu (dublowane i rozłożone na D :) jest realizowane przy użyciu skrzynki JBOD 4 x 4 TB.

Ze względu na 4 rdzenie procesorów i hiperwątkowanie spodziewałem się, że przełącznik Robocopy / MT: 8 będzie działał najlepiej i że więcej niż 8 wątków byłoby przesadzonych z powodu zarządzania wątkami nie będącymi beneficjentami.

Przetestowałem to. Podaję tutaj dane czwartej serii testowej (czas trwania w mm: ss):

 1 thread:  59:19
 2 threads: 39:12
 4 threads: 29:13
 8 threads: 24:36
16 threads: 24:19
32 threads: 24:27

To prawda, że ​​kilka sekund przy użyciu 16 wątków jest nieistotnych, ale są one spójne we wszystkich seriach testowych, tj. Nie z powodu większego obciążenia w teście mniejszym niż 16 wątków (chyba że tak było we wszystkich 4 seriach testowych). Zauważ również, że 32 wątki są prawie zawsze nieco szybsze niż 8 wątków.

Pytanie: jaki powód techniczny jest odpowiedzialny za użycie 16 wątków, które są bardziej wydajne niż 8 wątków na i7 z 4 rdzeniami hiperwątkowymi?

Odpowiedzi:


3

Wersja TL; dr: jeśli robisz coś bardzo obciążającego procesor, na przykład transkodowanie wideo przy użyciu Handbrake, nie chciałbyś używać więcej rdzeni niż procesorów, ponieważ nie byłoby miejsca na pracę do wykonania. W tym przypadku, gdy większość wątków spędza 90% swojego czasu na śnie, czekając na odczyty lub zapisy, mając więcej wątków, które działają raczej dla Ciebie niż przeciw.


Kopiowanie plików nie jest zadaniem szczególnie związanym z procesorem. Chociaż posiadanie większej liczby rdzeni może zapobiec blokowaniu narzędzia kopiującego przez inne zadania, jest mało prawdopodobne, aby każdy wątek działał w pobliżu 100% na każdym rdzeniu.

Każdy wątek kopiujący wyśle ​​żądanie odczytu na dysk twardy, a następnie przejdzie w tryb uśpienia, czekając na spełnienie żądania odczytu. Twój wirujący dysk z rdzeniem ma na ogół czas wyszukiwania wynoszący 9 milisekund, co jest praktycznie wiecznością pod względem procesora, a zadanie kopiowania nie obracałoby się po prostu, mówiąc „czy jest już gotowe?” i marnowanie cykli procesora. Spowodowałoby to zablokowanie tego wątku na 100% mocy procesora i marnowanie zasobów. Nie, dzieje się tak, że wątek wystawia odczyt, a wątek zostaje uśpiony, dopóki odczyt się nie zakończy i dane nie będą gotowe do następnego kroku.

W międzyczasie inny wątek robi to samo, zostaje zablokowany podczas odczytu i zostaje uśpiony. Dzieje się tak dla wszystkich 16 twoich wątków. (W rzeczywistości twoje odczyty i zapisy będą się pojawiać w przypadkowych momentach, gdy zsynchronizują się, ale masz pomysł)

Gdy jeden z wątków ma już gotowe dane, system Windows ponownie je planuje i rozpoczyna przetwarzanie w celu zapisania. W przypadku wątku proces jest taki sam. Mówi „zapisz te dane do pliku x w lokalizacji y”, a Windows pobiera dane i planuje wątek. System Windows działa w tle, aby dowiedzieć się, gdzie jest plik, przenosi dane (potencjalnie przez sieć, zwiększając opóźnienie o więcej milisekund), a następnie zwraca kontrolę w wątku po pomyślnym zapisie.

Żaden wątek nie pali się cały czas na rdzeniu procesora, więc więcej wątków niż masz procesorów nie stanowi problemu. Żaden wątek nie będzie wystarczająco długo przebudzony, aby stanowił problem.

Gdybyś miał tylko jeden procesor z dużą ilością innych wątków, mógłbyś mieć wąskie gardło na procesorze, ale w systemie wielordzeniowym z tego rodzaju obciążeniem byłbym zaskoczony, gdyby problem dotyczył procesora.

Bardziej prawdopodobne jest ograniczenie wydajności dysku twardego i uderzanie w głębokość kolejki buforów odczytu lub zapisu na dyskach. Używając większej liczby wątków, przesuwasz coś do granic możliwości, czy to na dysku, czy w sieci, a jedynym sposobem, aby dowiedzieć się, jaka jest najlepsza liczba wątków, jest zrobienie tego, co zrobiłeś i eksperymentowanie z tym.

W systemie z kopiowaniem SSD na SSD podejrzewam, że mniejsza liczba wątków mogłaby być lepsza, ponieważ byłoby mniej opóźnień niż kopiowanie plików z wirujących dysków twardych HDD, przepychanie przez sieć i pisanie do wirującej rdzy, ale nie mam dowodów popieraj to założenie.


Twoja odpowiedź jest bardzo doceniana, a także twoja uwaga na temat dysków SSD. Czy te uwagi na temat dysku SSD dotyczą również dysku twardego na dysk SSD lub dysku SSD na dysk twardy? (Nie chodzi o to, że dotyczy pytania, po prostu z braku zainteresowania.)
Herb

1
Jedynym sposobem, aby się dowiedzieć, jest wypróbowanie. Ale jeśli na ścieżce znajduje się dysk twardy, jego opóźnienia całkowicie zaabsorbują całkowity czas transferu. W przypadku dysków SSD na SSD ... typowy odczyt lub zapis SSD jest rzędu milisekundy, ale nadal jest to niewielki ułamek czasu procesora wymaganego do żądania następnego odczytu lub zapisu. tzn. nadal możesz znajdować się w sytuacji, w której dyski SSD nie są tak zajęte, jak to tylko możliwe.
Jamie Hanrahan
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.