Programy, które twierdzą, że nie są przyjazne dla wielu rdzeni

Od czasu do czasu widzisz to zdanie lub podobne, co ogólnie odnosi się do programu, który twierdzi, że nie zostały zaprojektowane w celu pełnego wykorzystania możliwości procesorów wielordzeniowych. Jest to powszechne zwłaszcza w przypadku programowania gier wideo. (oczywiście wiele programów nie ma współbieżności i nie potrzebuje jej, takich jak podstawowe skrypty itp.).

Jak to może być? Wiele programów (zwłaszcza gier) z natury korzysta z współbieżności, a ponieważ system operacyjny jest odpowiedzialny za planowanie zadań na CPU, to czy te programy z natury nie korzystają z wielu dostępnych rdzeni? Co w tym kontekście oznaczałoby „wykorzystanie wielu rdzeni”? Czy ci programiści faktycznie zabraniają planowania zadań systemu operacyjnego i wymuszają powinowactwo lub własne planowanie? (Brzmi jak poważny problem ze stabilnością).

Jestem programistą Java, więc może nie musiałem sobie z tym poradzić z powodu abstrakcji lub czegokolwiek innego.

Dobra współbieżność wymaga znacznie więcej niż rzucania kilku wątków w aplikację i liczenia na najlepsze. Istnieje pewien zakres, w jakim program może iść od żenująco równoległego do czysto sekwencyjnego. Każdy program może korzystać z prawa Amdahla do wyrażenia skalowalności problemu lub algorytmu. Kilka kwalifikacji do żenująco równoległego wniosku to:

• Brak stanu wspólnego, każda funkcja zależy tylko od przekazanych parametrów
• Brak dostępu do urządzeń fizycznych (kart graficznych, dysków twardych itp.)

Istnieją inne kwalifikacje, ale dzięki tym dwóm możemy zrozumieć, dlaczego gry nie są tak łatwe, jak mogłoby się wydawać, aby skorzystać z wielu rdzeni. Po pierwsze, model świata, który będzie renderowany, musi być współdzielony, ponieważ różne funkcje obliczają fizykę, ruch, stosują sztuczną inteligencję itp. Po drugie, każda klatka tego modelu gry musi być renderowana na ekranie za pomocą karty graficznej.

Szczerze mówiąc, wielu twórców gier korzysta z silników gier produkowanych przez strony trzecie. Minęło trochę czasu, ale te silniki gier innych firm są teraz znacznie bardziej równoległe niż kiedyś.

W przypadku efektywnej współbieżności istnieją większe wyzwania architektoniczne

Współbieżność może przybierać różne formy, od uruchamiania zadań w tle do pełnego wsparcia architektury dla współbieżności. Niektóre języki zapewniają bardzo zaawansowane funkcje współbieżności, takie jak ERLANG , ale wymaga to odmiennego myślenia o sposobie tworzenia aplikacji.

Nie każdy program naprawdę potrzebuje złożoności pełnego wsparcia dla wielordzeniowych procesorów. Jednym z takich przykładów jest oprogramowanie podatkowe lub dowolna aplikacja sterowana formularzem. Gdy większość czasu spędzasz na oczekiwaniu na coś od użytkownika, złożoność aplikacji wielowątkowych nie jest tak przydatna.

Niektóre aplikacje są bardziej krępująco równoległe, na przykład aplikacje internetowe. W tym przypadku platforma zaczyna się żenująco równolegle i to od Ciebie nie musisz narzucać rywalizacji.

Dolna linia:

Nie wszystkie aplikacje są naprawdę uszkodzone, ponieważ nie korzystają z wielu wątków (a tym samym rdzeni). W przypadku tych, których to boli, czasami obliczenia nie są przyjazne dla równoległego przetwarzania lub narzutu w celu jego koordynacji sprawiłby, że aplikacja byłaby bardziej delikatna. Niestety równoległe przetwarzanie nie jest jeszcze tak łatwe, jak powinno być, aby zrobić dobrze.

Wiele programów (zwłaszcza gier) z natury korzysta z współbieżności,

Nie, w rzeczywistości jest na odwrót. Większość aplikacji jest napisana w jednym wątku, a programiści nigdy nie wprowadzili niezbędnych zmian w celu obsługi współbieżności.

W językach C, C ++ i C # musisz wyraźnie powiedzieć aplikacji, aby uruchomiła nowe wątki i / lub procesy.

Myślę, że zbytnio koncentrujesz się na planowaniu wątków, a zbyt mało na przetwarzaniu danych w potencjalnych wątkach. Udostępnianie danych między wątkami i / lub procesami wymaga pewnej formy synchronizacji. Jeśli zmienisz aplikację tak, aby korzystała z wielu wątków, ale synchronizacja się nie powiedzie, prawdopodobnie będziesz mieć trudności z wyśledzeniem błędów w kodzie.

W przypadku wielowątkowych aplikacji, nad którymi pracowałem, generalnie nigdy nie martwiłem się o wysyłkę i tylko o synchronizację danych. Jedyną sytuacją, w której musiałem się martwić o wysyłkę, było ściganie warunków wyścigu z powodu nieprawidłowej synchronizacji danych.

Zasadniczo, gdy aplikacja mówi, że nie może używać wielu rdzeni, oznacza to, że nie ma synchronizacji w celu ochrony manipulacji danymi.

Nie chodzi tu o wiele rdzeni, ale o wiele wątków. System operacyjny może zaplanować uruchamianie wątku na dowolnym rdzeniu, który mu się podoba, a harmonogram ten jest przejrzysty dla planowanego programu. Jednak wiele programów nie jest pisanych przy użyciu wielu wątków, więc mogą działać tylko na jednym rdzeniu jednocześnie.

Dlaczego miałbym pisać program jednowątkowy? Są łatwiejsze do napisania i łatwiejsze do debugowania: jedna rzecz dzieje się po drugiej (zamiast dzieje się wiele rzeczy naraz i możliwe wzajemne oddziaływanie). Lub twój program może nie być ukierunkowany na komputery wielordzeniowe (tak jak w przypadku starych gier). W niektórych przypadkach program wielowątkowy może nawet działać wolniej niż wersja jednowątkowa, jeśli narzut związany z przełączaniem kontekstu i komunikacja między wątkami przewyższa prędkość uzyskaną przez równoległe wykonywanie (niektóre części programu mogą nie być równoległe).

To nie jest pełna odpowiedź. To jest przestroga.

Pewnego dnia pomyślałem, że pokażę studentom na moim równoległym kursie programowania równoległą szybką sesję. Myślałem, że Quicksort powinien się dobrze zrównoleglać. Użyłem dwóch wątków. Uruchomiłem go na moim komputerze z jednym rdzeniem. Wyniki były następujące:

• 14 sekund dla wersji jednowątkowej.
• 15 sekund dla wersji 2-wątkowej.

Chodziło o to, czego się spodziewałem.

Potem wypróbowałem to na nowszej, dwurdzeniowej maszynie.

• 11 sekund dla wersji jednowątkowej.
• 20 sekund dla wersji 2-wątkowej.

Dwa wątki dzieliły kolejkę pozostałych zadań. Wygląda na to, że pola obiektu kolejki były tasowane tam iz powrotem między pamięcią podręczną jednego rdzenia a drugim.