C++ | SDL2 - Wielowątkowość w pętli

[Isharoth 2167]

Cześć, zacząłem zabawę z wielowątkowością w C++ i jednej rzeczy nie rozumiem. Kiedy wrzucę joina do pierwszej pętli, wtedy program działa prawidłowo, ale jednak wolniej niż na pojedynczym wątku (co jest akurat zrozumiałe). Chciałbym jednak, żeby wszystkie wątki wykonały swoje zadanie, a główny wątek grzecznie poczekał aż wszystkie będą gotowe. Niestety gdy zrobiłem drugą pętlę, w której dołączam wszystkie wątki, to program się zamyka. W jaki sposób mogę to ugryźć?

 

std::thread t[8];
for (int j = 0; j < 8; ++j)
{
  t[j] = std::thread(&Map::threadDraw, this, j, tiles_size, Tiles);
}

for (int j = 0; j < 8; ++j)
{
  t[j].join();
}

 

Mam pętlę, która wykonuje się nawet kilkadziesiąt tysięcy razy (teraz pętla znajduje się w funkcji threadDraw). Podzieliłem to zadanie tak, aby każdy wątek miał do wykonania taką samą część pracy. Niestety nie wiem jak to zrobić w dobry sposób i z czego skorzystać, bo na pewno czegoś tu brakuje.

 

Doczytałem, że problem może powodować SDL (bo piszę grę). Podobno funkcje z SDL operujące na renderze, muszą być wykonywane na wątku, w którym ten renderer został stworzony. Tyle, że osoba która to pisała zaznaczyła, że dotyczy to sytuacji, w której wykorzystujemy OpenGL, podczas gdy ja mam obecnie DirectX. Jeśli rzeczywiście problem leży gdzieś tutaj to chyba sobie daruję wielowątkowość, bo musiałbym przepisać połowę kodu, a mam tydzień czasu na skończenie tego.

Z drugiej strony, wątpię że to akurat ten sam problem, bo przecież tak czy inaczej wykonuję to samo na różnych wątkach. Kwestia tego kiedy dołączę dany wątek, a niestety rozwiązanie jakie przedstawiłem wyżej kończy się crashem.

Edytowane 28 Kwietnia 2019 przez Isharoth

[winuser_pl 0]

Najbezpieczniej jest rysowac w jednym tylko watku i w 99,99% przypadkow to jest wystarczajace do osiagniecia liczby FPS ktorej potrzebujesz. Nie widze powodu dla ktorego mialbys renderowac w roznych watkach jednoczesnie. Bo na pewno nie jest to wydajnosc.

 

Powinienes rysowac w jednym watku i zrobic konstrukcje w ktorej polecenia pobierane sa z kolejki do ktorej dostep jest synchronizowany.

 

Alternatywna metoda - utworzyc sobie mutex i w momencie kiedy wywolujesz metode ktorej wynikiem sa calle do renderea przejmowac wlasnosc na tym mutexie. Czyli de facto tez synchronizowac rysowanie. W ten sposob sprawisz ze renderowanie bedzie thread safe.

[Isharoth 2167]

Jeśli chodzi o samo rysowanie to tak, niestety grę wcześniej pisałem bez myśli o wielowątkowości i teraz wychodzą takie problemy. Debuger wskazuje na RenderCopy, czyli jednak to jest to. Co ciekawe na DirectX gra crashuje, na OpenGL działa, ale nie rysuje poprawnie mapy.

Myślałem o wielowątkowości, bo każdy bloczek rysowany na mapie traktuję jako osobny obiekt. Więc w pętli w której rysuję mapę przy mapie 160x160 odwołuję się do 25600 obiektów, sprawdzam ich właściwości, animacje i renderuję na mapie w odpowiedniej pozycji. Na Ryzenie 2700X wychodzi około 90 fps, co nie jest zbyt dobrym wynikiem jak na grę 2D . Niestety trzeba by tu było część rzeczy przepisać. Zastanowię się jeszcze nad tym co napisałeś, bo sam póki co nie mam żadnych pomysłów.

Czytałem o tych mutexach, ale póki co nie ogarniam o co chodzi. Dzięki bardzo za propozycje!

[winuser_pl 0]

Problem polega na tym, ze nie ogarniasz programowania wspolbieznego. Doczytaj sobie o tym i o podstawowych mechanizmach synchronizacji.

 

Temat jest ciekawy i warty zglebienia

[MitycznyJeż 476]

Naiwne zrównoleglenie + synchronizacja może się skończyć gorzej niż wariant jednowątkowy...

 

Profilowałeś program, czy optymalizujesz "na pałę"?

[Isharoth 2167]

Profilowałeś program, czy optymalizujesz "na pałę"?

Na pałę nie. Wszystko dotyczy operacji która powtarza się najczęściej i zabiera sporo fps. Samo rysowanie mapy składającej się z 25600 bloczków i mam spadek z ~2500fps do 90 fps. Na pewno da się to zrobić w lepszy sposób, ale grę muszę mieć skończoną do następnego tygodnia (projekt na studia). Pewnie będę dalej nad tym pracować w ramach hobby. Problem w tym, że mam jedną prostą pętlę przy rysowaniu mapy, w której odwołuję się do każdego bloczku i rysuję jego teksturę w odpowiednim miejscu. No i tu moim gwoździem do trumny jest to, że SDLowe RenderCopy będzie zawsze wywoływane z poziomu klasy bloczku (a raczej mojego texture managera, do którego odwołuję się w tej klasie) i tu się cały program wysypuje przy wielowątkowości. Gdybym brał wcześniej pod uwagę, że będę próbował robić multithreading, to pewnie rozpisałbym to inaczej. Na początku myślałem, że będzie dało się rozłożyć tą prostą pętlę na wątki, jednak problem jest bardziej złożony, a ja pierwszy raz w ogóle ruszałem wielowątkowość przy programowaniu.

 

I tak już zoptymalizowałem co się dało, bo wcześniej było poniżej 60 fps przy tym samym rozmiarze mapy. Po prostu zrobię mniejsze mapki, a jak skończę robić tę grę, to i tak raczej przepiszę cały silnik od podstaw i to już nie na SDL, tylko czystym OpenGL, bo z shaderami też chciałbym się pobawić.

Edytowane 28 Kwietnia 2019 przez Isharoth

[MitycznyJeż 476]

Przy tygodniowym deadline odpuść jakąkolwiek wielowątkowość

 

Jeżeli coś by miało jakieś szanse zadziałać, to użycie wątków tak, by każdy niezależnie składał swoją 1/8 ostatecznego obrazu, i dopiero w głównym wątku to wszystko złożyć w całość. Jak i czy to wykonalne - mnie nie pytaj, nie tykałem SDL'a od lat

[winuser_pl 0]

samo rysowanie mapy składającej się z 25600 bloczków i mam spadek z ~2500fps do 90 fps

Zastanawia mnie po co Ci 2500 fps? 90 fps to dobry wynik, chociaz na pewno mozna go poprawic, jednak bedzie to kosztowalo troche czasu.

 

Bez wiekszej ilosci kodu trudno bedzie pomoc

 

Twoj problem polega na tym, ze program nie dostarcza wystarczajaco szybko danych do potoku karty graficznej. Profilowanie byloby wskazane. Nawet najprostsze i lopatologiczne na poczatek z manadzerem zadan i programem GPU-Z i interesuje Cie "gpu load".

[Isharoth 2167]

Zastanawia mnie po co Ci 2500 fps? 90 fps to dobry wynik, chociaz na pewno mozna go poprawic, jednak bedzie to kosztowalo troche czasu.

 

Tak, ale jak 90 fps mam na 2700X, to ile będzie na słabszych CPU? Właśnie o to się martwiłem, tym bardziej jakbym chciał zrobić jeszcze większe mapy. Przed optymalizacją na moim laptopie było jakoś ~40fps, bardzo słabiutko jak na grę 2D, a to tylko mapa z bloczkami, które mają swoje właściwości. A za optymalizację też będę oceniany. Cały spadek wydajności obraca się tylko wokół tej jednej, prostej pętli w której wywołuję metodę update dla 25 tys. obiektów, dlatego właśnie to chciałem rozdzielić na wątki.

GPU raczej nie ma za dużo do roboty.

 

W grze działa mi nawet OSD z Afterburnera, więc wszystko mam pod ręką. Użycie GPU na minimalnym taktowaniu skacze od 5 do 30%. Zwracam jednak szczególną uwagę na CPU, bo nawet gdy na próbę zakomentowałem całą metodę update, to zobaczyłem, że samo wywoływanie tylu obiektów zabiera aż tyle fps. A jeden wątek CPU jest prawie cały czas na 100%.

 

Haha, problem leżał w mojej iteracji wektora. Po zmianie pętli na:

 

for (auto& i : Tiles)
{
  i->update();
}

całość działa 4 razy szybciej.

Edytowane 28 Kwietnia 2019 przez Isharoth

[winuser_pl 0]

Pokaz poprzednia wersje

Sprawdzasz to na konfiguracji debug? Bo jesli tak to jest kompletnie niemiarodajne.

[Isharoth 2167]

Wcześniej było tak:

 

for (int i = 0; i < tiles_size; i++)
{
	Tiles[i]->update();
}

 

 

Ok, po zmianie sposobu iteracji miałem 390fps, teraz po zmianie konfiguracji na release mam ~1500. Problem z głowy, bez wielowątkowości (ale i tak do tego przysiądę). Dzięki za pomoc.

[Bono[UG] 1618]

Jest ktoś w stanie wytłumaczyć skąd taka różnica w wydajności między tymi dwiema pętlami?

Na moje oko i to co znalazłem w sieci, to nie powinno być tak dużej różnicy.

[Luk4s 21]

Operator [] wykonuje dodatkowe operacje do sprawdzenia czy jesteśmy in range.

[winuser_pl 0]

operator[] nie wykonuje sprawdzenia zakresu.

iterowanie po zakresach powoduje uzycie kilku sprytnych optymalizacji - doczytaj w necie bo duzo by wymieniac.

[MitycznyJeż 476]

Autor dokonał zmiany jeszcze w momencie, gdy prowadził "pomiar" w debug.

A tam - przynajmniej w implementacji ms - operator[] sprawdza zakres.

[Bono[UG] 1618]

To ciekawie by było porównać obie wersje w release.

[Isharoth 2167]

Chętnie sprawdzę jutro i dam znać. Bo dziś siedziałem nad tym tyle, że nawet nie mam już więcej ochoty wracać do Visual Studio.

 

Na release nie widzę różnicy.

Edytowane 3 Maja 2019 przez Isharoth