Optymalizacja symulatora

[panthero]

Witam serdecznie wszystkich użytkowników - jestem nowy na forum, ale Waszego Dzieła używam już od dawna - kolej kochałem także od dawna. Od dawna jestem także programistą - pascal/delphi, c/c++, java i asembler. Zakładam ten wątek ponieważ chce poznać zdanie programistów symulatora na temat sensowności wykonania optymalizacji funkcji użytych w tymże symulatorze i przepisania ich całkowicie jako tak samo funkcjonalne, ale bezpośrednio języku asemblera - mam na myśli np. fizykę. Sam symulator zdaje mi się - po oględzinach być napisany w Delphi, lub C++ Builderze Borlanda. Naprawdę Wasz projekt jest niesamowitym przedsięwzięciem i chyląc czoło wszystkim, którzy pracowali nad symulatorem - oferuję moje umiejętności pisania w języku asemblera x86 (jako całej rodziny tego typu procesorów) aby zoptymalizować najbardziej obliczeniowo obciążające procesor metody poszczególnych klas, których zapewne użyliście w tym symulatorze. Wiem, że po prostu możecie nie uwierzyć w moje umiejętności programowania ogólnie dlatego - zapraszam na http://panthero.republika.pl. To takie moje małe portfolio - hehs - niby programy w Javie pod platformę J2ME, ale one niech będą potwierdzeniem, że potrafię programować obiektowo. A efekty moich prac w asemblerze, które de facto powstały w czasie moich studiów, a które dalej trwają mogę przesłać zainteresowanym - teraz z grupą kolegów na studiach wprawdzie tworzymy - dydaktycznie w asemblerze prosty system operacyjny, ale naprawdę wielkim zaszczytem byłoby dla mnie gdybym mógł także pomóc w pracach nad tak wspaniałym projektem jakim jest MaSzyna:) Zaznaczam - to nie jest kolejny post typu - proszę o źródła - wcale ich nie chcę i nie potrzebuję - developerzy wiedzą o co mi chodzi - wystarczy ciało jednej metody - która ma wykonać złożone obliczenia, a ja mogę napisać taką samą w asemblerze - maksymalnie ją optymalizując. Oczywiście niekiedy nie można pisać "wyrwanych z kontekstu" metod, ale myślę, że dam radę:)
Pozdrawiam:)

[queuedEU]

Witam, i jednoczenie nie rospisujac sie o zawilosci i balaganie w kodzie zaproponuje funkcje Ground.Update(dt, n);, ale jako ze to jest zbyt obszerne to moze cos innego... uno momento ...

[youBy]

Witam, i jednoczenie nie rospisujac sie o zawilosci i balaganie w kodzie zaproponuje funkcje Ground.Update(dt, n);, ale jako ze to jest zbyt obszerne to moze cos innego... uno momento ...

To akurat jest dosyć dobrze zrobiona funkcja jednak :)

[queuedEU]

Ok youBy, ja wymiekam, kmpletnie nic mi w tej chwili nie trafia do glowy, moze Ty cos wystaw w koncu lepiej znasz waskie gardla

[queuedEU]

ale to nie jest koncert zyczen...

Ooo! teraz jestes GW bardzo elo i pro...

A generalnie rzecz biorac to ta dyskusja jenak raczej nie jest na forum, bo i tak do niczego nie doprowadzi...

Takie rzeczy powinna osoba zainteresowana przedyskutowac z kims kto siedzi w kodzie dluzszy czas na spokojnie na jakims im.

[panthero]

Ok, w końcu znów siedzę przed komputerem, bo wracałem do domu z Opola - swoją drogą - 3 x Kiblem podróż czasem może być męcząca, a czasem fascynująca - dziś to drugie, ale do rzeczy.

Tak pobieżnie czytam te Wasze posty i przyznaję, że nie ogarniam całego forum - jeśli wcześniej się podobny temat postu do mojego pojawił, to przepraszam za powtórzenie. Sedno całej sprawy - z mojego punktu widzenia jest takie - nie neguję tego, że symulator jest optymalnie napisany:
 

Witam, i jednoczenie nie rospisujac sie o zawilosci i balaganie w kodzie zaproponuje funkcje Ground.Update(dt, n);, ale jako ze to jest zbyt obszerne to moze cos innego... uno momento ...

To akurat jest dosyć dobrze zrobiona funkcja jednak :)

Po prostu - w Delphi pisze od kilku lat, funkcje "inline" asemblera też już pisałem - teraz na studiach zabrałem sie ostro za "myślenie" w asemblerze z dobrym efektem, więc pomyślałem, że mogę jakoś się Wam przydać. Przyznam się na przykład, że też próbowałem (na projekt) zrobić grę w OpenGL(Tetris) ale jakoś to zarzuciłem, zaliczyłem czym innym - jednak pojęcie o tym pewne mam - ale mnie najbardziej chodzi o doraźne przepisanie metod typowo obliczeniowych - koprocesor, liczby nawet z precyzją większą niż double (tbyte) to wszystko potrafię wykorzystać - instrukcję typu MMX i SEE też można wykorzystać. Ogólnie temat rzeka. Naprawdę chce też coś dać od siebie - kabin ani modeli nie zrobię bo grafik ze mnie marny, ale programowaniem mogę pomć.

[Ra]

Myślę, że potencjał może być w wykorzystaniu równoczesnego (równoległego?) mnożenia liczb zmiennoprzecinkowych...

[panthero]

Myślę, że potencjał może być w wykorzystaniu równoczesnego (równoległego?) mnożenia liczb zmiennoprzecinkowych...

A to m. in. można właśnie uzyskać na określonych instrukcjach SSE - http://pl.wikipedia.org/wiki/Streaming_SIMD_Extensions

Wszystkie nowsze procesory - od Pentium III wzwyż to posiadają, więc można tą technologię wykorzystać. Jednym słowem - wiem, że w OpenGL np. w określaniu współrzędnych wykorzystuje się typ Single. Rejestr XMM w SSE może jednocześnie przeprowadzić CZTERY równoległe operacje mnożenia na tym typie. Możliwości są - nie można ich nie wykorzystać. Ja proponuję coś takiego - napiszę sobie np. w Delphi jakiś program, który będzie wykonywał jakieś złożone obliczeniowo operacje. I zrobię go w dwóch lub trzech wersjach - pierwsza "normalna" tj. bez wstawek asemblerowych, druga - wstawki asemblera, ale tylko z wykorzystaniem FPU i trzecia - wstawki asemblera z wykorzystaniem MMX/SSE. Następnie przesłałbym to chętnym developerom, a oni mogliby wyrazić swoje zdanie i odrzucić lub ewentualnie zaaprobować mój pomysł.

[Winger]

Mi sie pomysl podoba, tymbardziej iz to wlasnie liczenie fizyki jest najwiekszym obciazeniem starego projektu. Jesli mozna to uproscic/zoptymalizowac, to czemu nie?
Ktokolwiek ma najnowsza wersje kodu, niech ja koledze Panthero udostepni.

[youBy]

150 FPS w Mocznikach mam, gdy renderuje się tylko kabina; Normalnie w granicach 15 - 30, a
maksimum wyciągane na moim sprzęcie to jakieś 350-400 FPS. Jak widać to rendering daje ostro po czasie przetwarzania.
(Dane zostały zebrane przypadkowo podczas testów funkcji - wynik negatywny).

A najbardziej aktualne źródła ma chyba @KURS90.

[panthero]

150 FPS w Mocznikach mam, gdy renderuje się tylko kabina; Normalnie w granicach 15 - 30, a
maksimum wyciągane na moim sprzęcie to jakieś 350-400 FPS. Jak widać to rendering daje ostro po czasie przetwarzania.
(Dane zostały zebrane przypadkowo podczas testów funkcji - wynik negatywny).

A najbardziej aktualne źródła ma chyba @KURS90.

Oczywiście przetwarzanie grafiki w największym stopniu będzie obciążać... no właśnie co - w OpenGL operuje się na tzw. primitives - w zasadzie podejście do programowania grafiki w OpenGL nie jest podejściem czysto obiektowym - jeśli dla ułatwienia sobie pracy programiści "opakowali" w klasy zbiory funkcji OpenGL'a to faktycznie duża ilość obiektów nie będzie wpływać na spowolnienie renderowania - dzisiejsze karty graficzne są kilkakrotnie bardziej skomplikowane w architekturze zewnętrznej niż dzisiejsze CPU, spowolnienie bierze się ze specyficznego operowania obiektami w programie - zależy też jak są wiązane metody - czy statycznie, czy w tzw. runtime - to już się przedkłada na szybkość działania gdyż zawsze przed wywołaniami metod odpowiednio są obliczane ich adresy a to spowalnia - zwłaszcza przy wielu obiektach... Temu zaradzić za bardzo się nie da bo wszystko trzeba by od nowa - z innym podejściem pisać, nie w tym rzecz. Przecież nawet w metodach klas odpowiedzialnych za tworzenie i "układanie" wierzchołków można wykorzystać instrukcje SIMD - a najlepiej tam gdzie na większej liczbie nie powiązanych ze sobą danych (współrzędne wierzchołków) wykonuje się takie same operacje. Większość aplikacji, które korzystają z OpenGL używa także natywnych funkcji OpenGL np GL_NV_... ale na tym niestety się nie znam.

Podsumowując - owszem to karta graficzna (i jej sterownik) zajmuje się przetwarzaniem i realizowaniem poleceń OpenGL, ale... dane wierzchołków - ich współrzędne oblicza procesor. Tak samo zresztą wykrywanie kolizji - tego OpenGL nie zrobi - to wszystko robota CPU - optymalizując funkcje obliczające wierzchołki i całą resztę graficznych detali - można znacząco przyspieszyć wydajność aplikacji. Aha - ja na razie źródeł nie chcę - miną tygodnie zanim pewnie - doczytam się o co chodziło developerom - z całym szacunkiem dla Was - to Wy wiecie gdzie są "wąskie gardła" - na razie potrzebna mi taka jakby "dokumentacja" Waszego projektu - pro prostu - jak poradzono sobie z konkretnymi rzeczami - czy projekt używa wielu wątków, jak zorganizowano program w klasy itp. Potem można zacząć właściwą pracę - nie można tuningować silnika w aucie znając tylko metody tuningu - trzeba znać i silnik i całe auto.

[ABu]

Tak samo zresztą wykrywanie kolizji - tego OpenGL nie zrobi - to wszystko robota CPU

Kolizje są poza podejrzeniami. Detekcji kolizji z prawdziwego zdarzenia w symulatorze nie ma. Jest pseudodetekcja - ale tylko z pojazdami znajdującymi się na torze. To są bardzo proste funkcje, dodatkowo wywoływane niezwykle rzadko (raz na sekundę albo nawet rzadziej).
Fizyka, włącznie z Ground.Update(); również nie będzie raczej wąskim gardłem. O ile aktualne źródła są wersją zoptymalizowaną przeze mnie to jest tam zastosowana sprytna sztuczka pozwalająca zdecydowanie uprościć liczenie. Cała fizyka (siły między sprzęgami, przesunięcia) liczona jest na pociągu rozciągniętym tylko w jednym wymiarze, dopiero potem pociąg jest wpasowywany w tor. Umożliwia to wyrzucenie ogromnej liczby obliczeń funkcji trygonometrycznych. Fakt, że jest to uproszczenie, ale błędy są pomijalnie małe, za to obserwowany wzrost wydajności znaczny.

Gdybym miał sugerować kierunek optymalizacji to wybrałbym optymalizację grafiki, bo to jest zdecydowanie najwęższe gardło obecnej wersji.

Pozdrawiam

[panthero]

Dzięki @KURS90 mam aktualne źródła i muszę przyznać, że łącznie z header'ami ponad 2 000 000 linii kodu robi wrażenie. Do rzeczy - obecnie od dłuższego czasu pracuję nad przenosinami kodu pod C++ Builder 6 - jakoś się udaje - trochę jest błędów w header'ach, ale powoli praca postępuje - jeśli po kompilacji symulator zadziała normalnie to przyjrzę się bliżej źródłom odpowiedzialnym za 3D - jest tam sporo zamieszania, ale widziałem już kilka funkcji, które ładnie będą mogły być zoptymalizowane.

[acze]

Witajcie; Jestem tu nowy, ale dorzucę swoje 3 grosze, myślę, że nikt się nie obrazi :).

Asembler w tym projekcie to raczej dobry wybór, zwłaszcza, że cały projekt powstał z tego co słyszałem w cepie.

Zastanawiam się jednak czy tu chodzi o to, że kod jest wolny algorytmicznie, czy koncepcyjnie.

<cite>Oczywiście niekiedy nie można pisać "wyrwanych z kontekstu" metod, ale myślę, że dam radę:)</cite>
Co racja to racja; aczkolwiek w jezykach obiektowych enkapsulacja jest jak najbardziej zalecana; kod powinien być jak najbardziej uniwersalny i pozwalać się używać w wielu miejscach.

PS. jak koordynujecie pracę nad kodem? Jakiś system wersjonowania, typu CVS, SVN? Forum developerskie?

PS2. Jestem programistą javy, z 3 letnim doświadczeniem; przed tym przez 5 lat programowałem w c pod dosem i linuksem. Interesuję się fizyką przemian cieplnych, troszkę fizyką ruchu. Zapoczątkowałem projekt openrail.net . Jeśli mogę się na coś przydać, to chętnie pomogę, zwłaszcza koncepcyjnie.

[uetam]

Mhm, skoro tyle sie dzieje  moze warto zalozyc dla symka konto na sourceforge lub znow postawic traca i svna?

[jageer]

Przepraszam za być może głupie pytanie, ale czy jest możliwość zrobienia tzn jakiegoś szybkiego przeprogramowania symka pod procki i systemy 64-bitowe ?? Czy raczej jest to niemożliwe, bo wiąże się z robieniem wszystkiego "prawie" od nowa ?

[ShaXbee]

Mhm, skoro tyle sie dzieje  moze warto zalozyc dla symka konto na sourceforge lub znow postawic traca i svna?

Planowalem to zrobic w zeszlym tygodniu ale niestety lenistwo przemoglo checi do pracy - postaram sie postawic w dlugi weekend te uslugi.

Przepraszam za być może głupie pytanie, ale czy jest możliwość zrobienia tzn jakiegoś szybkiego przeprogramowania symka pod procki i systemy 64-bitowe ?? Czy raczej jest to niemożliwe, bo wiąże się z robieniem wszystkiego "prawie" od nowa ?

Ze tak brzydko sie zapytam - Po cholere? Jesli oczekujesz od przejscia na 64bity wzrostu wydajnosci mozesz sie srogo zawiesc, poza tym nie sadze zeby kod symka pisany pod BC++ bylby mozliwy do przekompilowania pod kompilatorem supportujacym x64

[Krzysiek626]

Przepraszam za być może głupie pytanie, ale czy jest możliwość zrobienia tzn jakiegoś szybkiego przeprogramowania symka pod procki i systemy 64-bitowe ?? Czy raczej jest to niemożliwe, bo wiąże się z robieniem wszystkiego "prawie" od nowa ?

Może mnie nie zabiją,
słyszałem że były takie próby, nie wyszło z tego nic zachęcającego.

[bohunIC]

Czy te zabiegi nie przypominają aby próby zrobienia z PACMANA czegoś w stylu GTA? I tak nic z tego nie wyjdzie więc po co się męczyć.

[Poscikk]

Zawsze jakieś fps można jeszcze wydusić, tym bardziej, że ludzie dysponują teraz duuuużo potężniejszymi komputerami niż 3 lata temu. Porównując niektóre gry z naszym symkiem, mam w nich tyle samo fpsu co w MaSzynie(np. crysis). Oczywiście nie wszędzie. A to zapewne dowód na to, że można jakieś działania poczynić, aby trochę szybciej to wszystko działało. Co do wersji 64-bit: 100% poparcia dla ShaxBee'ego. To przysforzy tylko więcej problemów niż jest dotychczas. Także wersja x64 mija się całkowicie z celem, ale prace optymalizacyjne jak najbardziej są wskazane(a przynajmniej próby zrobienia czegokolwiek w tym kierunku).

[youBy]

Zawsze jakieś fps można jeszcze wydusić, tym bardziej, że ludzie dysponują teraz duuuużo potężniejszymi komputerami niż 3 lata temu.

Szczególnie, że mojemu bije już 6 rok...

[Monczan_SP32]

Zawsze jakieś fps można jeszcze wydusić, tym bardziej, że ludzie dysponują teraz duuuużo potężniejszymi komputerami niż 3 lata temu.

Szczególnie, że mojemu bije już 6 rok...

Mimo wszystko symek zawsze miał o te pare klatek mniej, niż powinien mieć przy takim wyglądzie. Wiadomo, fizyka liczy się bardziej, wiem to, żeby nie było :)