Wątki kontra procesy w .NET

Question

Mam długotrwały proces, który odczytuje duże pliki i zapisuje pliki podsumowań. Aby przyspieszyć, jestem przetwarzanie wielu plików jednocześnie stosując regularne stare wątki:

ThreadStart ts = new ThreadStart(Work); 
Thread t = new Thread(ts); 
t.Start(); 

Co odkryłem, że nawet z oddzielnych wątków czytania pojedynczych plików i brak blokady między nimi i za pomocą 4 wątki na 24 -pokrywarka, nie mogę nawet uzyskać do 10% na procesorze lub 10% na dysku I/O. Jeśli używam więcej wątków w mojej aplikacji, wydaje mi się, że działa ona jeszcze wolniej.

Przypuszczam, że robię coś złego, ale gdy robi się ciekawy, to jeśli uruchomię cały exe drugi i trzeci raz, to faktycznie przetwarza pliki dwa i trzy razy szybciej. Moje pytanie brzmi: dlaczego nie mogę uzyskać 12 wątków w mojej aplikacji do przetwarzania danych i opodatkowania urządzenia, a także 4 wątków w 3 przypadkach mojej aplikacji?

Profilowałem aplikację, a najbardziej czasochłonne i często nazywane funkcje są wywołaniami ciągów.

Answer 1

Spróbuj użyć biblioteki zadań z .net 4 (System.Threading.Task). Ta biblioteka ma wbudowane optymalizacje dla różnej liczby procesorów.

nie mają pojęcia co to ty problem, być może dlatego, że fragment kodu nie jest naprawdę pouczające

Answer 2

Jest możliwe, że problem nie jest obliczeniowa procesora związany, ale I/O związany. Nie pomaga stwierdzenie, że dysk we/wy ma "tylko 10%". Nie jestem pewien, czy taki licznik wydajności istnieje.

Powodem, dla którego robi się wolniej podczas korzystania z większej liczby wątków, jest to, że wszystkie wątki próbują dostać się do odpowiednich plików w tym samym czasie, podczas gdy podsystem dysku ma problemy z zapełnieniem wszystkich wątków. Widzisz, nawet przy użyciu nowoczesnej technologii, takiej jak dyski SSD, w których czas wyszukiwania jest o kilka rzędów wielkości mniejszy niż w przypadku tradycyjnych dysków twardych, wciąż istnieje kara pieniężna.

Należy raczej stwierdzić, że problem jest związany z dyskiem, a pojedynczy wątek prawdopodobnie będzie najszybszym sposobem rozwiązania problemu.

Można argumentować, że można użyć technik asynchronicznych do przetworzenia bitów, które zostały przeczytane, podczas gdy w tle czytany jest następny fragment, ale myślę, że zauważysz tam bardzo niewielkie polepszenie wydajności.

Mam podobny problem nie tak dawno temu w małym narzędziu, w którym chciałem obliczyć podpisy MD5 wszystkich plików na moim dysku twardym i odkryłem, że procesor jest zbyt szybki w porównaniu do systemu pamięci masowej i uzyskałem podobne wyniki, starając się uzyskać większą wydajność, korzystając z większej liczby wątków.

Korzystanie z zadania Biblioteka równoległa nie złagodziło tego problemu.

Answer 3

Przede wszystkim na 24-rdzeniowym pudełku, jeśli używasz tylko 4 wątków, najwięcej procesorów, z których mógł korzystać, to 16,7%, więc naprawdę uzyskujesz 60% wykorzystania, co jest dość dobre.

Trudno powiedzieć, czy twój program jest związany w tym momencie z I/O, domyślam się, że tak właśnie jest. Musisz uruchomić profiler na swoim projekcie i zobaczyć, które sekcje kodu twój projekt poświęca najwięcej czasu. Jeśli siedzi na operacji odczytu/zapisu, jest związany we/wy.

Możliwe jest użycie jakiejś formy blokady między wątkami. To spowodowałoby spowolnienie programu w miarę dodawania kolejnych wątków, a tak, uruchomiłby się drugi proces, ale naprawiłoby to również blokowanie.

To wszystko sprowadza się do braku informacji o profilowaniu, nie możemy powiedzieć, że jeśli drugi proces przyspieszy lub spowolni działanie, musimy wiedzieć, czy program zawiesił się na operacji wejścia/wyjścia, blokowanie operacja lub po prostu długi czas w funkcji, która może być lepiej zrównoleglona.

Answer 4

Myślę, że dowiesz się, jaka pamięć podręczna plików nie jest idealna w przypadku, gdy jeden proces zapisuje dane w wielu plikach jednocześnie. Pamięć podręczna plików powinna zostać zsynchronizowana z dyskiem, gdy liczba brudnych stron pamięci podręcznej przekroczy próg. Wydaje się, że współbieżni pisarze w jednym próg uderzenia o proces szybciej niż pisarz pojedynczego wątku. Możesz przeczytać czytać o pamięci podręcznej systemu plików tutaj File Cache Performance and Tuning