Konfiguracja wątków w oparciu o nr rdzeni CPU

Moim zaleceniem jest zapewnienie przełączników config i command-line do przypisywania liczby wątków na maszynę. Użyj heurystyki opartej na uruchomieniu.getRuntime ().availableProcessors() jak wskazują inne odpowiedzi tutaj, w przypadkach, gdy użytkownik / Administrator nie skonfigurował aplikacji w inny sposób. I mocno polecam przed wyłącznym heurystycznym odgadywaniem wątków, z kilku powodów: [5]}

• Większość nowoczesnego sprzętu zmierza w kierunku coraz bardziej niejednoznaczne typy "wątków sprzętowych": modele SMT, takie jak Hyperthreading Intela i moduły obliczeniowe AMD, komplikują formuły (szczegóły poniżej), a odpytywanie tych informacji w czasie wykonywania może być trudne.

• Większość nowoczesnych urządzeń ma funkcję turbo, która skaluje prędkość w oparciu o aktywne rdzenie i temperatury otoczenia. Wraz z rozwojem technologii turbo zakres prędkości (ghz) rośnie. Niektóre najnowsze układy Intel i AMD mogą wahać się od 2,6 ghz (wszystkie rdzenie aktywne) do 3,6 ghz (pojedynczy / dwurdzeniowy active), co w połączeniu z SMT może oznaczać, że każdy wątek uzyskuje efektywną przepustowość 1,6 ghz - 2,0 ghz w poprzednim projekcie. Obecnie nie ma możliwości odpytywania tych informacji w czasie wykonywania.

• Jeśli nie masz silnej gwarancji, że Twoja aplikacja będzie jedynym procesem działającym na systemach docelowych, ślepe zużywanie wszystkich zasobów procesora może nie zadowolić użytkownika lub administratora serwera (w zależności od tego, czy oprogramowanie jest aplikacją użytkownika lub aplikacją serwera).

Nie ma solidny sposób, aby wiedzieć, co dzieje się w pozostałej części maszyny W czasie pracy, bez zastępowania całego systemu operacyjnego własnym domowym jądrem wielozadaniowym. Twoje oprogramowanie może próbować zgadywać poprzez odpytywanie procesów i Podglądanie obciążeń CPU itp., ale jest to skomplikowane, a użyteczność jest ograniczona do określonych typów aplikacji (z których Twoje może się kwalifikować) i zazwyczaj korzysta z lub wymaga podwyższonego lub uprzywilejowanego poziomu dostępu.

• Nowoczesne skanery antywirusowe teraz-dni pracy poprzez ustawienie specjalnej flagi priorytetu dostarczanej przez nowoczesne systemy operacyjne, np. pozwalają OS powiedzieć im, kiedy "system jest bezczynny". OS opiera swoją decyzję nie tylko na obciążeniu procesora: bierze również pod uwagę dane wejściowe użytkownika i flagi multimedialne, które mogły być ustawione przez odtwarzacze filmowe itp. Jest to w porządku w przypadku głównie bezczynnych zadań, ale nie jest przydatne do zadań obciążających procesor, takich jak twoje.

• Rozproszone aplikacje komputerowe do domu (BOINC, Folding@Home, itp.) działają poprzez zapytania uruchamianie procesów i systemowe obciążenie procesora okresowo -- może raz na sekundę lub pół sekundy. Jeśli zostanie wykryte obciążenie procesów nienależących do aplikacji dla wielu zapytań z rzędu, aplikacja zawiesi obliczenia. Gdy obciążenie spadnie na pewną liczbę zapytań, wznawia się. Wiele zapytań jest wymaganych, ponieważ odczyty obciążenia CPU są notorycznie z powodu krótkich skoków. Nadal istnieją zastrzeżenia: 1. Użytkownicy nadal są zachęcani do ręcznej rekonfigurowania BOINC, aby pasował do specyfikacji ich maszyny. 2. jeśli BOINC jest uruchamiany bez uprawnień administratora, to nie będzie wiedział o procesach uruchomionych przez innych użytkowników (w tym niektóre procesy usługowe), więc może niesprawiedliwie konkurować z tymi o zasoby procesora.

Odnośnie SMT( HyperThreading, moduły obliczeniowe):

Większość SMT będzie obecnie raportować jako rdzenie sprzętowe lub wątki, co zwykle nie jest dobre, ponieważ niewiele aplikacji działa optymalnie, gdy jest skalowane na każdym rdzeniu systemu SMT. Na domiar złego, zapytanie, czy rdzeń jest współdzielony (SMT) lub dedykowany, często nie daje oczekiwanych wyników. W niektórych przypadkach sam system operacyjny po prostu nie wie (Windows 7 nie jest świadomy projektu współdzielonego rdzenia AMD Bulldozer, na przykład). Jeśli możesz uzyskać niezawodną liczbę SMT, zasadą jest policzenie każdego SMT jako pół wątku dla zadań obciążających procesor i jako pełnego wątku dla zadań głównie bezczynnych. Ale w rzeczywistości waga SMT zależy od tego, jaki rodzaj obliczeń wykonuje, a cel Architektura. Implementacje SMT Intela i AMD zachowują się niemal przeciwstawnie, na przykład-Intel jest silny w wykonywaniu zadań załadowanych liczbami całkowitymi i operacji rozgałęziających się równolegle. AMD jest silny w obsłudze SIMD i pamięci ops równolegle.

Jeśli Chodzi O Funkcje Turbo:

Większość procesorów w dzisiejszych czasach ma bardzo skuteczną wbudowaną obsługę Turbo, która jeszcze bardziej zmniejsza wartość uzyskaną ze skalowania wszystkich rdzeni systemu. Co gorsza, funkcja turbo jest czasami opierając się tak samo na rzeczywistej temperaturze systemu, jak na obciążeniach procesora, więc system chłodzenia samej wieży wpływa na prędkość tak samo jak specyfikacje procesora. Na przykład na konkretnym AMD A10 (Bulldozer) zaobserwowałem, że działa na 3,7 ghz na dwóch wątkach. Zmniejszył się do 3,5 ghz po uruchomieniu trzeciego wątku i do 3,4 ghz po uruchomieniu czwartego. Ponieważ jest to również zintegrowany GPU, spadł aż do około 3,0 ghz, gdy działały cztery wątki Plus GPU (procesor A10 wewnętrznie daje pierwszeństwo GPU w scenariuszach dużego obciążenia); ale nadal może gromadzić 3,6 ghz z 2 wątkami i aktywnym GPU. Ponieważ moja aplikacja używała zarówno procesora, jak i GPU, było to krytyczne odkrycie. Udało mi się poprawić ogólną wydajność, ograniczając proces do dwóch wątków związanych z procesorem (pozostałe dwa współdzielone rdzenie były nadal pomocne, służyły jako wątki obsługi GPU - potrafiły się obudzić i szybko reagować na przesyłanie nowych danych do GPU, w razie potrzeby).

... ale w tym samym czasie, mój zastosowanie gwintów 4x mogło być znacznie lepsze w systemie z zainstalowanym urządzeniem chłodzącym wyższej jakości. To wszystko jest takie skomplikowane.

Wniosek: nie ma dobrej odpowiedzi, a ponieważ dziedzina projektowania CPU SMT / Turbo ciągle się rozwija, wątpię, że w najbliższym czasie pojawi się dobra odpowiedź. Każda porządna heurystyka, którą dziś sformułujesz, może jutro nie przynieść idealnych rezultatów. Więc moja rekomendacja brzmi: nie trać na to dużo czasu. Rough-guess something based on core counts to dobrze pasuje do lokalnych celów, pozwól, aby zostało nadpisane przez config / switch i przejdź dalej.

Możesz uzyskać liczbę procesorów dostępnych dla JVM w następujący sposób:

Runtime.getRuntime().availableProcessors()

Obliczanie optymalnej liczby wątków z liczby dostępnych procesorów nie jest jednak niestety trywialne. Zależy to w dużej mierze od charakterystyki aplikacji, na przykład z aplikacji CPU związane z większą liczbą wątków niż liczba procesorów nie ma sensu, podczas gdy Jeśli aplikacja jest głównie związane IO możesz chcieć użyć więcej wątków. Należy również wziąć pod uwagę konto, jeśli w systemie działają inne procesy wymagające dużej ilości zasobów.

Myślę, że najlepszą strategią byłoby empiryczne ustalenie optymalnej liczby wątków dla każdej konfiguracji sprzętowej, a następnie wykorzystanie tych liczb w aplikacji.

Zgadzam się z innymi odpowiedziami tutaj, które zalecają podejście najlepiej zgadywać, i zapewniając konfigurację dla nadpisania domyślnych.

Ponadto, jeśli Twoja aplikacja jest szczególnie obciążona procesorem, możesz przyjrzeć się "przypinaniu" aplikacji do określonych procesorów.

Nie mówisz, jaki jest twój podstawowy system operacyjny, ani czy obsługujesz wiele systemów operacyjnych, ale większość ma na to jakiś sposób. Na przykład Linux ma zestaw zadań .

Powszechnym podejściem jest unikanie CPU 0 (zawsze używanego przez system operacyjny) i ustawianie powinowactwa procesora aplikacji do grupy procesorów znajdujących się w tym samym gnieździe.

Utrzymywanie wątków aplikacji z dala od cpu 0 (i, jeśli to możliwe, z dala od innych aplikacji) często poprawia wydajność, zmniejszając ilość przełączania zadań.

Utrzymywanie aplikacji na jednym gnieździe może dodatkowo zwiększyć wydajność poprzez zmniejszenie unieważniania pamięci podręcznej podczas przełączania wątków aplikacji wśród procesorów.

Podobnie jak Wszystko inne, jest to w dużym stopniu zależne od architektury maszyny, na której pracujesz, a także od tego, jakie inne aplikacje są uruchamiane.

Użyj narzędzia VisualVm do monitorowania wątków.Najpierw Utwórz Minimalne wątki w programie i zobacz jego wydajność.Następnie zwiększ liczbę wątków w programie i ponownie przeanalizuj jego wydajność.Niech ci to pomoże.

Używam tego skryptu Pythona tutaj, aby określić liczbę rdzeni (i pamięci, itp.) uruchomienie aplikacji Java z optymalnymi parametrami i ergonomią. PlatformWise na Github

Działa to tak: napisz skrypt Pythona, który wywołuje getNumberOfCPUCores() w powyższym skrypcie, aby uzyskać liczbę rdzeni i getSystemMemoryInMB(), Aby uzyskać PAMIĘĆ RAM. Możesz przekazać tę informację do swojego programu za pomocą argumentów wiersza poleceń. Twój program może następnie użyć odpowiedniej liczby wątków w oparciu o liczbę rdzenie.

Tworzenie wątku na poziomie aplikacji jest dobre i w procesorze wielordzeniowym wykonywane są osobne wątki na rdzeniach w celu zwiększenia performance.So aby wykorzystać moc przetwarzania rdzenia, najlepszą praktyką jest wdrożenie gwintowania.

Co myślę:

1. w tym czasie TYLKO 1 Wątek programu będzie uruchamiany na 1 rdzeniu.
2. Ta sama aplikacja z 2 wątkami będzie uruchamiana w połowie czasu na 2 rdzeniach.
3. Ta sama aplikacja z 4 wątkami będzie działać szybciej na 4 rdzeń.

Zatem rozwijana aplikacja powinna mieć poziom wątku

Czas wykonywania wątku jest zarządzany przez system operacyjny i jest wysoce nieprzewidywalną czynnością. Czas wykonania procesora jest znany jako wycinek czasu lub kwant. Jeśli tworzymy coraz więcej wątków, system operacyjny spędza ułamek tego czasu na decydowaniu, który wątek pójdzie pierwszy, zmniejszając w ten sposób Rzeczywisty czas wykonania każdego wątku. Innymi słowy każdy wątek wykona mniejszą pracę, jeśli w kolejce będzie duża liczba wątków.

Przeczytaj to, aby dowiedzieć się, jak właściwie wykorzystać zawartość cpu core.Fantastic. csharp-codesamples.com/2009/03/threading-on-multi-core-cpus/

Obliczanie optymalnej liczby wątków z liczby dostępnych procesorów nie jest niestety trywialne. Zależy to w dużej mierze od charakterystyki aplikacji, na przykład z aplikacji CPU związane z większą liczbą wątków niż liczba procesorów nie ma sensu, podczas gdy Jeśli aplikacja jest głównie związane IO możesz chcieć użyć więcej wątków. Należy również wziąć pod uwagę, czy w systemie działają inne procesy wymagające dużych zasobów.