Optymalizacja symulatora

[panthero]

Więc na początek - kilka godzin męczyłem się wczoraj z portowaniem kodu z BC++B 5 na BC++B 6 - z marnym skutkiem - wprawdzie udało się ogarnąć błędy występujące zarówno w czasie kompilacji jak i linkowania, ale efekt był marny - symek nie ładował obrazków ani dźwięków - słowem tragedia. Z tego co przekazał mi @KURS90 to symek nie za bardzo chciał kompilować się w innym środowisku niż BC++ 5. Ale trzeba iść z duchem czasu więc ściągnąłem i zainstalowałem Turbo C++ Explorer - najnowsze dziecko Borlanda z tej rodziny i tutaj wszystko pięknie działa bez dodatkowych zmian w kodzie (mały rebuilt unitów pascalowych). Mam więc bazę i jako tako przyznaję - nie wszystko tutaj rozumiem, ale na początek zabieram się za optymalizację biblioteki odpowiedzialnej za obliczenia na wektorach - to będzie pierwszy punkt pracy. Na razie tyle.

Przenoszę.
Akvin

[panthero]

Co w zasadzie mam zamiar zrobić w kodzie:

• obliczenia na wektorach w pełni w SSE - doświadczalnie sprawdziłem, że skalary wcale nie muszą być typu double(podwójna precyzja) - to w zasadzie pozwala na spokojną pracę bez wymogów procesora z SSE2. Funkcje obliczające wyznaczniki - pozbycie się - małych porcji kodu(det2x2), na rzecz większego kodu, obrabiającego jednocześnie wiele danych w trybie SIMD. (wyznacznik 3x3 macierzy przepisany na nowo w SSE - poprzednia wersja enkapsulowała det2x2 - nawet gdy det2x2 jest w SSE to efekt jest odwrotny - spowolnienie - gdyż zbyt mało danych jest do obróbki,a kilka instrukcji trzeba poświęcić na rozmieszczenie danych w rejestrach)
• ogólnie wepchnięcie wstawek asemblera gdzie się da - i gdzie to nie zaszkodzi
• ciągle analizuję kod - może pewne klasy da się zoptymalizować...

Na razie tyle

[Ra]

Trzeba uważać z pozycjami obiektów zapisanymi w typie single. Typ ten ma mantysę 23 bit, czyli niecałe 7 cyfr dziesiętnych. Jeśli oddalimy pojazd od środka układu o 8km mamy niedokładność obliczeń rzędu 1mm. Przy 83km daje to już 10mm drgań wynikających z błędów obliczeń z użyciem takiej mantysy. (Scenerie raczej nie mają większego promienia.)

Kiedyś w symulatorze objawiało się to zwiększonymi drganiami przy oddalaniu się od środka, po czym zostało poprawione - podejrzewam, że poprzez zwiększenie typu. Może się wydawać, że wszystko jest dobrze, póki się jest niedaleko od początku układu współrzędnych. Ale w odległości np. 100km od środka będzie już rzucało.

Dobrym rozwiązaniem mogłoby być przemieszczanie środka układu współrzędnych. Ale nie wiem na ile zaawansowanych zmian to wymaga. Można by podzielić scenerię na kratki wielkości np. 8km, a numer kratki trzymać w oddzielnym bajcie.

Innym rozwiązaniem może być przechowywanie pozycji jako int z wartością w [mm]. Tylko wtedy dochodzą konwersje na typ zmiennoprzecinkowy do obliczeń. (Też trzeba przemieszczać początek układu robiąc dzielenie modulo, jedynie pamiętanie współrzędnej obiektów wymaga 32 bitów, a nie 64.)

[uetam]

Kiedyś w symulatorze objawiało się to zwiększonymi drganiami przy oddalaniu się od środka, po czym zostało poprawione - podejrzewam, że poprzez zwiększenie typu. Może się wydawać, że wszystko jest dobrze, póki się jest niedaleko od początku układu współrzędnych. Ale w odległości np. 100km od środka będzie już rzucało.

yb właśnie poprawił to rzucanie. Jestem po testach - 100 km od środka układu nie trzęsie nic a nic.

[Krzysiek626]

Kiedyś w symulatorze objawiało się to zwiększonymi drganiami przy oddalaniu się od środka, po czym zostało poprawione - podejrzewam, że poprzez zwiększenie typu. Może się wydawać, że wszystko jest dobrze, póki się jest niedaleko od początku układu współrzędnych. Ale w odległości np. 100km od środka będzie już rzucało.

yb właśnie poprawił to rzucanie. Jestem po testach - 100 km od środka układu nie trzęsie nic a nic.

@Mateu, sprawdziłeś to na starym byku? Chodzi jeszcze o prawidłowe bujanie kamery.
Pytanie, jak optymalizacja exe może wpłynąć na szybkość ładowania scenerii?
W przypadku dobrze wypasionych scn ten czas obecnie dochodzi do kilkunastu minut.

[youBy]

Ja zastosowałem sztuczkę, iż przy oddaleniu się o więcej niż 10 km od początku układu współrzędnych cała sceneria zostaje przesunięta o 10km w "tył". Nie wiem jak wyglądają wyniki po 40-50 przeskokach (sądzę, że nie ma problemów, ale to trzeba zbadać dogłębnie).

Pytanie, jak optymalizacja exe może wpłynąć na szybkość ładowania scenerii?
W przypadku dobrze wypasionych scn ten czas obecnie dochodzi do kilkunastu minut.

Moim zdaniem przydałyby się scenerie binarne, ale zrobienie tego może wymagać głębokich modyfikacji kodu.

[janek32]

Moim zdaniem przydałyby się scenerie binarne, ale zrobienie tego może wymagać głębokich modyfikacji kodu.

Takie scenerie są w TRS?

[uetam]

Moim zdaniem przydałyby się scenerie binarne, ale zrobienie tego może wymagać głębokich modyfikacji kodu.

Takie scenerie są w TRS?

Y, ale co to ma wspolnego z tematem? Nikomu nie bedzie sie chcialo robic importu jezeli do tego zmierzasz ;]

[youBy]

Przy optymalizacji należałoby również dokonać prób z wielordzeniowością procesorów (zawsze to troszkę więcej FPS będzie). Moje pierwsze próby wykazały tendencję spadkową, być może ze względu na złe podejście do sprawy, gdyż nie zajmowałem się tym kiedykolwiek wcześniej.

[kj]

Programowanie wielowątkowe pociąga za sobą problem synchronizacji i blokowania danych. Problem wczytywania plików definiujących obiekty 3D faktycznie możnaby rozwiązać przy użyciu konwersji na formaty binarne (odpada konieczność parsowania pliku). Z teksturami może być nieco gorzej. Wczytywanie tekstur można by zaimplementować przy użyciu mapowania pliku w pamięci (w POSIX: mmap(), w Win32 - niestety nie wiem, nie programuję pod tą platformę). Moje małe testy wykazały 4-krotne przyspieszenie przy wczytywaniu pliku o rozmiarze 1MB oraz ponad 30-krotne w przypadku pliku o rozmiarze 10MB.

Jeśli chodzi o wstawki asemblerowe i ogólnie przepisywaniu kodu do asemblera - faktycznie, użycie SSE(2) może tutaj pomóc, jednak samo używanie wstawek w kodzie nie zawsze jest zalecane. Wstawki burzą optymalizacje, wprowadzane przez kompilator, dlatego dobrze by było dokładnie rozważyć, czy wstawienie wstawki w danym miejscu kodu przyniesie więcej pożytku, czy szkody.

Odniosę się jeszcze do pisania symulatora w dwóch językach. Może lepiej przepisać wszystko .pas na .cpp lub .c? Kompilatory Pascala mają złą sławę jeśli chodzi o jakość generowanego kodu. Nie wspomnę już o tym, że sam Pascal ma w sobie pewne mechanizmy, które są przydatne do wyszukiwania błędów, ale niekorzystnie wpływają na wydajność.

Oprócz tego warto się też zapoznać z dwoma dokumentami firmy AMD, dokładnie omawiającymi problem optymalizacji programu:
1, 2