Tak jak w temacie dlaczego Rust jest gorszy od C++ w GameDevie? Czy naprawdę Rust 1.80 jest wolniejszy o 30% od C++? Macie jakiś rzetelny benchmark?
https://www.reddit.com/r/Zig/comments/1cf3dj9/leaving_rust_gamedev_after_3_years/
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-gpp.html
https://www.reddit.com/r/rust/comments/1cdqdsi/lessons_learned_after_3_years_of_fulltime_rust/
https://www.reddit.com/r/rust_gamedev/comments/17qr30r/where_do_you_guys_think_rust_gamedev_will_be_in/
https://www.reddit.com/r/rust_gamedev/comments/107lmra/is_it_a_good_idea_to_start_learning_game/
- Rejestracja:8 miesięcy
- Ostatnio:8 miesięcy
- Postów:7
0
Rust edytowany 1x, ostatnio: Programator_
Wibowit
a czy ten post nie nadawałby się bardziej do działu Gamedev ?
Programator_
Moderator przeniesie czy ja?
- Rejestracja:prawie 22 lata
- Ostatnio:8 minut
- Postów:6628
- Rejestracja:ponad 2 lata
- Ostatnio:około godziny
- Postów:48
1
@Programator_: Według mnie może chodzić o dostępność bibliotek. Większość rozwiązań jest oparta na C++. Ten język jest dość mocno zakorzeniony w branży i minie mnóstwo czasu zanim zostanie zastąpiony przez coś innego. Poza tym korzyści jakie wynikają z zastosowania Rusta nie będą niwelować problemu z tworzeniem wielu rzeczy od nowa. Po prostu C++ jest sprawdzony i posiada wiele sprawdzonych rozwiązań, zaś użycie Rusta może być ryzykowne i kosztowne. Warto również dodać, że Rust jest znacznie mniej popularny od C++ i znacznie ciężej znaleźć programistów znających go. Dla większości producentów jest po prostu nieopłacalny.
Rust sam w sobie nie jest gorszy od C++, ale C++ jest bardziej popularny oraz jest wiele sprawdzonych technologii opartych na nim.
- Rejestracja:ponad 15 lat
- Ostatnio:około 8 godzin
1
Uuuu, przez sugerowanie, że rust się do czegoś nie nadaje narażasz się na gniew rusto seksualnych wyznawów z reddita.
Czy naprawdę Rust 1.80 jest wolniejszy o 30% od C++?
W uśrednionych zastosowaniach ogólnych - nie. I rust i C++ możesz wyskalować by osiągnąć taki perf jaki potrzebujesz. Czasem koszt czasowy osiągnięcia pożądanej wydajności jest korzystniejszy dla C++ bo przez wiele lat dorobił się bibliotek, które przyspieszają sprawę, no i zawsze możesz sobie zejść do C.
edytowany 2x, ostatnio: several
- Rejestracja:około 11 lat
- Ostatnio:2 minuty
- Postów:8401
0
Jest taka strona, gdzie są linki do bibliotek GameDev w Rust:
https://arewegameyet.rs/
choć nie wiem, na ile aktualna.
Według mnie może chodzić o dostępność bibliotek.
Myślę, że pod kątem samej dynamiki ekosystemu, to Rust to taki trochę jak JavaScript sprzed dziesięciu lat (porównuję dynamikę ekosystemu, a nie technologię!).
Ekosystem JS teraz się już ustabilizował mniej więcej, ale w JS też kiedyś wymyślali różne rzeczy, a potem wychodziły z mody i ciągle zostawały zastępowane. I nie było jednego standardu, a jak był, to był toporny (teraz w Rust zdaje się Bevy jest popularny, próbowałem coś w tym robić, ale dla mnie to strasznie ciężkie jest. Masę zależności, żeby zrobić HelloWorld).
A w Rust nawet jak jest modna biblioteka do gier/grafiki, to za kilka lat przestaje być modna/utrzymywana.
Dlaczego Rust nie nadaje się do GameDev?
Jak jesteś indie hobbystą, to wszystko się nadaje do GameDev, w czym ci się wygodnie pisze (chociaż Rust ma duży próg wejścia).
edytowany 4x, ostatnio: LukeJL
- Rejestracja:około 6 lat
- Ostatnio:dzień
2
Spine napisał(a):
@Programator_: Rust nadał się do wskrzeszenia Gamedevu :] https://ruffle.rs/
nic wielkiego bo dawno jest coś takiego w javascript / typescript:
https://awayfl.org/
https://swf2js.com/en/
awayfl działa jakby płynniej i wygląda jakoś lepiej - jakby ruffle nie miało wygładzania krawędzi (testowałem side to side na pobranych z https://ruffle.rs/demo animacjach).
Zużycie procesora identyczne, zużycie pamięci 2x mniejsze na korzyść rusta - ruffle 115MB, awayfl 230MB
Programator_ napisał(a):
Czy naprawdę Rust 1.80 jest wolniejszy o 30% od C++? Macie jakiś rzetelny benchmark?
Wątpię, natomiast czy ma to jakiekolwiek znaczenie? Poza jakimiś symulacjami i może grami AAA gdzie wykorzystuje się możliwości sprzętu do końca to może ma ale większość gier ma minimalne zużycie CPU i większość się dzieje na GPU.
Pamiętam kilkadziesiąt lat temu jak się bawiłem w pascalu na komputerze z procesorem 16MHz który spokojnie płynnie ogarniał na ekranie 10000 jednostek (kropek) z jakąś tam prostą logiką.
edytowany 5x, ostatnio: obscurity
- Rejestracja:ponad 15 lat
- Ostatnio:około 8 godzin
2
ale większość gier ma minimalne zużycie CPU i większość się dzieje na GPU
Jeśli mówimy o high endowych gierkach AAA to zużycie CPU jak najbardziej ma znaczenie i UE jest właśnie krytykowany przez fakt, że nie potrafi w pełni wykorzystać obecnej technologii przez co łatwo nadziać się na czkawki w postaci spadków FPS albo brakujących klatek. Był to jeden z tematów gdy CDPR ogłosił że przechodzi na UE, bo ichniejszy RedEngine w Cyberpunk fantastycznie potrafił wykorzystać CPU i nie zamierzają wykorzystywać UE bez własnych modyfikacji właśnie z tego powodu.
ps. Screenshot z cyberpunku pokazujący jak że potrafi działać płynnie gdy ma dostepne tylko intelowe e-cores.
https://x.com/CapFrameX/status/1705949917976445181
edytowany 3x, ostatnio: several
Na ile to był błąd silnika, a na ile programisty? Dobry programista by zrobił benchmarki czy perf i znalazł miejsce w kodzie, które spowalnia wszystko.
Lol no rzeczywiście, jeden programista zrobił błąd i teraz cała kobyła pod tytułem UE ma problem z zużyciem procka :D
@several: ale ja bym wolał wyjaśnienie bardziej szczegółowe, takie jak podałeś to jest tak jakbyś na mnie napluł, ja bym chciał wiedzieć, czy jest jakiś bottlenek danych, albo nie wykorzystują GPU tylko na CPU mielą wszystko. Nawet trudno mi wyobrazić sobie co mogli tam zrobić, raczej odpowiedź w stylu bo programista źle napisał UE to mnie nie satysfakcjonuje.
To możesz zacząć od obejrzenia drugiego filmuki digital foundry który podlinkowałem. Ten post to nie jest artykuł techniczny wyjaśniający problemy UE a odpowiedź na twierdzenie, że CPU w grach nie jest obciążone.
CPU pipeline GPU wywołuje, ale dobrze wiedzieć, że nikt nie potrafi UE ogarnąć.
CDPR i CreativeAssembly planują zmerdżować jakieś swoje zmiany do głównego brancha by poprawić sytuację. Drugi film traktuje o jakiś ich prezentacjach gdzie traktują jakie modyfikacje zrobili w silniku dla siebie, ale nie mogę tych prezentacji znaleźć.
@several: ja się zastanawiam czy używając wszystkich narzędzi profilowania procesów i z kodem źródłowym nie zauważyli by anomali w dłuższym wykonywaniu kodu i nie mogli by tego opisać jakoś sensownie co spowodowało taki problem z wydajnością. Praktycznie da się każdej funkcji wykonanie co do milisekundy wyświetlić, znając jej nazwę można się spodziewać czy jakieś skomplikowane obliczenia robi czy coś prostego.
@.GodOfCode.: to czy aplikacja się dobrze skaluje na wiele rdzeni zależy od jej ogólnej architektury. ja się na silnikach gier nie znam, ale coś kojarzę, że początkowe mechanizmy zrównoleglania polegały na tym, że były wydzielone wątki do obsługi różnych podsystemów, np. osobny jeden wątek od obsługi dźwięku, itd. dzisiaj przechodzi się na dzielenie pracy na małe zadania i rozrzucanie tych zadań na wszystkie rdzenie. w zależności od tego jak skutecznie dzielisz pracę na zadania i jaki jest narzut na komunikację między rdzeniami, zrównoleglenie może być efektywne lub nie.
problem z unreal engine 5 jest też taki, że wykorzystuje pierdylion różnych shaderów, a ich kompilacja trwa i powoduje przycięcia. nie wiem czy w ogóle da się ten problem rozwiązać, bez uciekania rozwiązań typowych np. dla javy (kompilacja jit, tiered compilation, on stack replacement, itp itd). prekompilacja shaderów chyba jest średnio wykonalna, bo architektur kart graficznych jest wiele, a poza tym użytkownik może zmienić wersję sterowników i juz stare prekompilowane shadery trzeba wyrzucić. na konsolach jest prościej, bo tam się nic nie zmienia w konfigu sprzętu i softu
@Wibowit: jit, akurat w wielu językach jak python robi tak, że pierwsze uruchomienie tworzy wersję na dysku skompilowanej wersji, czyli następne uruchomienie ma podręką, ale jak ktoś dobrze nie przebada tego UE co powoduje błąd to tylko obrzucanie wszystkich winą, za coś co może być drobnostką, którą przez nie uwagę powoduje wszystkie te problemy. Ktoś to musi wszystko przeanalizować i dojść do sedna problemu.
@.GodOfCode.:
jit, akurat w wielu językach jak python robi tak, że pierwsze uruchomienie tworzy wersję na dysku skompilowanej wersji, czyli następne uruchomienie ma podręką - python jedyne co robi to tłumaczy kod źródłowy na ichniejszy bajtkod. to jest porównywalne z kompilacją plików .java do .class, czyli nie jest to jeszcze kompilacja do kodu natywnego. te techniki co podałem wcześniej (czyli kompilacja jit, tiered compilation on stack replacement) to techniki wykorzystywane do generowania coraz lepszego kodu natywnego (tzn. coś a'la na początku -O0, a na końcu -O3).
@Wibowit: miałem na myśli numbe i jaxa, ogólnie kompilowane jity robią na dysku ich reprezentację i potem korzystają z niej. Czysty python to co najwyzej do bytecode jak wspomniałeś czyli .pyc pliku
miałem na myśli numbe i jaxa - aa dobra, no faktycznie są biblioteki do pythona generujące natywny kod. tak czy siak, z tym jitem to chodziło mi głównie o tiered compilation, a więc przy pierwszym uruchomieniu shadera jest on kompilowany bardzo szybko (to minimalizuje przestoje przy pierwszym uruchomieniu), ale do mało wydajnego kodu, a potem jest odpalany i jednocześnie (równolegle do wykonywania shadera) kompilowany z lepszymi optymalizacjami, a potem mniej zoptymalizowany shader jest wyrzucany i zastępowany lepiej zoptymalizowanym. myślę, że to byłoby kiedyś wykonalne.
@Wibowit: właśnie nie znam kompilacji shadera, ale kod typu libgccjit, się łatwo kompiluje, shadery mają swój pipeline do GPU, trzeba kiedyś to zrozumieć tak żeby w dyskusji potem móc się kłócić, bo tak to nie wiem dokładnie jak działają, chodź programowałem wiele razy, jedna funkcja, która dla każdego pixela się uruchamia bez pętli całą tablicę jednocześnie przejdziesz, jako parametry idx i idy bierze tylko.
ja już klepałem compute shadery hobbystycznie (implementowanem algorytmy sortowania na gpu), więc co nieco wiem jak działają. jednak nie schodziłem niżej niż opencl c (openclowa wersja języka c), więc nie znam szczegółów implementacyjnych i ograniczeń sprzętu, więc nie wiem jakie jest prawodpodobieństwo, że tiered compilation kiedyś wejdzie.
@Wibowit: shadery się łatwo programuje, piszesz raz kod, który w funkcji dostaje x i y i masz przewidzieć dla danego pixela wartość, dzięki czemu jedna funkcja jest na tysiącach rdzeni wykonana i jednocześnie jeden shader dla każðego pixela się wykona jest to mega efektywne, ale za to ciężko się programuje, te pipeline co dodali w UE i Unity to jednak robią robotę, łatwo wiele zjawisk łączyć.
problem z unreal engine 5 jest też taki, że wykorzystuje pierdylion różnych shaderów Nie tylko. Jeśli wierzyć komentarzom na YT to CDPR zamierza całkowicie zrezygnować z domyślnego streamingu danych, które w UE nazywają WorldPartition, który zawiera takie systemy jak LOD i temu podobne. Z innych, podobno system aktorów również jest nie wydajny przy większych projektach.
- Rejestracja:prawie 6 lat
- Ostatnio:około 6 godzin
- Postów:131
1
Popatrzcie też pod kątem ludzi, bo to raczej ważne. Prowadzicie firmę, zatrudniacie od lat wielu specjalistów. Wchodzi boom, rzucamy c++ na rzecz rusta, bo jest szybszy.
- Programiści żeby się przestawić będą potrzebować z roku. Żeby wyspecjalizować w niuansach kolejnych paru lat.
- Zatrudnić nowych, rustowych? To też problem. W gd rozwiązuje się specyficzne zagadnienia, czy to graficzne czy algorytmiczne.
- Zrobić stop na rok? Raczej mało kogo na to stać.
Nawet łatwiejszy a trudny przypadek - piszę w c# więc mogę wskoczyć na hop do backendu stronek? No nie - nie znam się na bazach, zabezpieczeniach sieciowych, dockerach itd.
edytowany 1x, ostatnio: Boski
Programiści żeby się przestawić będą potrzebować z roku - to jest jeden z powodów, dla którego nowe języki programowania zwykle zdobywają popularność powoli, latami (czy nawet dekadami). Poczekajmy z 5-10 lat. Z czasem pewnie coraz więcej będzie programistów Rusta i nie będą musieli się przestawić, bo będą go znać.
- Rejestracja:8 miesięcy
- Ostatnio:8 miesięcy
- Postów:12
0
Chciałbym żeby Rust miał taką prostą składnię jak Hylo, Vale. Do tego Hylo skopiował bezpieczeństwo pamięci z Rusta tylko dodał do tego mniejszą i prostszą składnię.
https://docs.hylo-lang.org/language-tour/functions-and-methods
https://vale.dev/