Új hozzászólás Aktív témák

• #48911 S_x96x_S addikt awexco #48910

  Új Válasz 2025-05-16 05:33:44 #48911

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  S_x96x_S

  addikt

  válasz awexco #48910 üzenetére

  > Volt valami mélyelemzés , vagy interjú ahol rávilágítottak az UE5 egyik gondjára

  interjú - "Lex Fridman Podcast #467 with Tim Sweeney" : #48892
  
  > Fillér baszás az UE5 igazi gondja . Amíg valaki nem fizet ,
  > hogy jó legyen addig nem is lesz jó !

  Ez egy olyan probléma - ami túl komplex és nehéz megoldani úgy,
  hogy sima legyen az átmenet.

  https://lexfridman.com/tim-sweeney-transcript#chapter25_concurrency
  
  (gépi fordítással )
  """"
  Concurrency :
  
  (03:13:33) Talán beszélhetnél a párhuzamosságról? Mi az abban a Verse-ben, ami lehetővé teszi a párhuzamosságot azon a skálán, amire szükségetek van?
  Tim Sweeney
  (03:13:41) Ez a legnagyobb műszaki probléma, amelyet ebben a generációban megpróbálunk megoldani, és ez a párhuzamosság megszelídítése úgy, hogy bármely átlagos programozó csupán szokványos kód írásával el tudja érni.
  Lex Fridman
  (03:13:57) Nehéz, igen.
  Tim Sweeney
  (03:13:59) Egy szálon futó számítógépen programozni már önmagában elég nehéz, de teljesen kiszámítható. Ha van egy determinisztikus nyelved, és mindig ugyanazt a kódot futtatod újra és újra, akkor pontosan ugyanazt fogja csinálni, nincs benne semmi kiszámíthatatlan, igaz? Változókat olvasol és írsz egy bizonyos sorrendben, és mindig ugyanúgy fog viselkedni.
  (03:14:19) A problémát az jelenti, amikor több szálat vagy több csomópontot vetsz be egy adatközpontban, amelyek egyetlen feladaton dolgoznak együtt: mindegyikük különböző adatrészeket akar olvasni és írni, miközben folyamatosan változtatják a világ állapotát. Ma a valós programokban a párhuzamosságot még mindig szinte kivétel nélkül manuálisan valósítják meg. A programozók nagyon-nagyon óvatosan írják meg azt a kódot, amely több szálon is futhat, hogy minden szál között „alkudozva” biztosítsák az adathozzáférést és a kiszámítható eredményeket.
  (03:14:53) És ez hihetetlenül nehéz. Olyan nehéz, hogy az Unreal Engine öt generációja során minden alkalommal úgy döntöttünk, hogy nem próbáljuk meg kézzel párhuzamosítani a játékkódunkat. Túl nagy a hibázás esélye – nemcsak a saját csapatunk, hanem minden partnercég számára is, akik licencelik az Unreal Engine-t és játékot építenének rajta. Ez egyszerűen hatalmas lábbelilövés.
  (03:15:17) A párhuzamosságra többféle megoldás létezik, de mind elég rossz kompromisszum. Egy próbálkozás az volt, hogy egyszerűen ne is próbáljuk megoldani ezt a problémát, hanem bontsuk le a programunkat mikroszolgáltatásokra. A nagy forgalmú weboldalak, például az amazon.com, majdnem kivétel nélkül több száz mikroszolgáltatással dolgoznak, ahol a különböző szerverek üzeneteket küldenek egymásnak, és a programozók nagyon óvatosan megírják ezeket, így végül megbízhatóan feldolgozzák a rendeléseket anélkül, hogy káoszba fulladna a rendszer.
  (03:15:48) De ez egyáltalán nem skálázható a metaverzumra, ahol milliók programoznak majd, és közülük a többség nem lesz számítógéptudós, hanem hobbi‐ és elsőkörös programozó, akik szórakozásból kódolnak. Ez nekik sosem fog működni, mert soha nem fogják tudni átlátni a különböző, párhuzamosan futó számítások közötti függőségeket.
  (03:16:07) Ám kiderült, hogy az 1980-as években készült egy fantasztikus alapkutatás, amelyet a Haskell‐párhuzamosságról szóló tanulmány tett igazán élettelivé. A „Composable Memory Transactions” (Összetételezhető memóriatranzakciók) című tanulmány leírja a tranzakciós frissítések rendszerét a programokban. A tranzakció egy kódrészlet, amely memórián végez műveleteket: olvas, ír, feldolgozhat egy megrendelést, elfogadhat vagy elutasíthat egy rendelést, pénzt utalhat egyik bankszámláról a másikra, vagy feltételes döntéseket hozhat, mint például: „Át szeretnél utalni száz dollárt erről a számláról erre a számlára. Megnézzük, van-e száz dollárod. Ha nincs, elutasítjuk. Ha van, levonjuk a százezret az egyik számládról, és hozzáadjuk a másikhoz.”
  (03:16:56) Tranzakciók nélkül, ha mindenki véletlenszerűen adogatja-veszi egymás bankszámláit, akkor előfordulhat, hogy valaki leolvassa a számlaegyenleget, levon száz dollárt, és kiírja az újat, miközben közben valaki más már írt valamit a számlára. Így következetlen egyenlegek jöhetnek létre, ha nincs mód arra, hogy garantáljuk az összes művelet meghatározott sorrendben történő lefutását.
  (03:17:16) A tranzakciók lényege, hogy az egész programot önálló frissítésekre bontjuk, amelyek tetszőleges számú számítást végezhetnek, de egyetlen szálon kell futniuk. A játék­motor esetében ez egy játékelem‐frissítés. Amikor a Fortnite‐ot játszod, minden játékosjelenet egy játékelem. Minden ellenfél, rakéta, lövedék, autó és mozogva kölcsönható dolog külön játékelem. Ezek nem statikus, rögzített világ­részletek, hanem külön objektumok. Ezeket az objektumokat másodpercenként 60 képkocka sebességgel, képkockánként egyszer frissítjük.
  (03:17:52) Tehát a Fortnite Battle Royale során tízezer‐tízezernyi objektumfrissítés történik minden egyes képkockában, száz játékos mellett. Egy milliárdos játékosszámú szimulációban ennél még sokkal több frissítés lenne.
  Lex Fridman
  (03:18:04) Jelenleg ez egyszálon van megvalósítva?
  Tim Sweeney
  (03:18:05) Igen, minden játékmunkamenetben egyszálúan fut. Emiatt van százfős limite a Fortnite‐ban. Ha maximálisan kihasználnád egy szervert, talán ma 140‐ig fel tudnád tornázni, de nem ezrekig, milliókig vagy milliárdokig.
  (03:18:18) Tehát szükségünk van egy módszerre, amellyel mágikusan, automatikusan skálázhatjuk a kódunkat. A tranzakciók adják a megoldást. A tranzakció egy olyan kódrészlet, amely teljes egészében lefut. A tranzakciós memóriakoncepció lényege, hogy a programozók teljesen szokványos módon írnák meg a kódot – változókat olvasnának és írnának rendesen, és nem kellene foglalkozniuk a párhuzamossággal. A rendszer (ma a számítógép) egyszerűen csak futtatja a programot, nyelvi spekuláció nélkül.
  (03:18:50) A tranzakciók ötlete, hogy mivel van egy sor művelet, amelyeket alkalmazni kell, ezeket nagyszámúan, párhuzamosan futtatjuk, de ahelyett, hogy mindegyik közvetlenül a globális memóriába írna, a módosításokat helyileg, tranzakciónként egyetlen pufferen tartjuk. Így a kód számára úgy tűnik, mintha a globális rendszerben dolgozna, befolyásolva a globális játékállapotot, de valójában elkülönítetten, csak az adott tranzakcióhoz tartozóan gyűjtjük a változtatásokat, és később vesszük őket számításba. Tízesével, százasával vagy ezresével futtatjuk ezeket az frissítéseket párhuzamosan, majd megnézzük, melyek ütköztek: ha két tranzakció nem olvasta vagy nem írta ugyanazt az adatot, bármilyen sorrendben vagy akár egyszerre is lefuthattak volna, és az eredmény ugyanaz marad.
  (03:19:51) Igen, a sorrend nem számít. Ez elképesztő. Elképesztő elképzelni egy olyan rendszert, amely tetszőlegesen párhuzamosan futtat milliónyi játékelem-frissítést – ez teszi lehetővé, hogy beszéljünk arról, amiről beszélünk, vagyis hogy tízmilliók legyenek együtt egy jelenetben.
  Tim Sweeney
  (03:20:13) Pontosan. A kulcs az, hogy ezeket a frissítéseket spekulatívan futtatjuk, és csak akkor írjuk ki a memóriába a változtatásokat, ha biztosak vagyunk, hogy ütközésmentesek. Tehát frissíthetsz 10 000 objektumot, és ha 9 000-nél nincs ütközés, akkor azokat beírjuk a memóriába – bármilyen sorrendben futhattak, és az eredmény változatlan.
  (03:20:33) Ez nagyon menő.
  Tim Sweeney
  (03:20:34) Marad ezer objektum. Azokat újra kell futtatni, más sorrendben vagy másképp összefésülve, hogy végül memóriába commitálódjanak. Közben az összes számítást eldobjuk, és később újra elvégezzük.
  (03:20:47) Ezzel a megközelítéssel áthelyezzük a fájdalmat – nem a programozóra hárítjuk, hanem a nyelvtervezőkre. Így a milliók helyett csak néhányszáz embernek kell komoly erőfeszítést tennie, hogy ez működjön.
  Lex Fridman
  (03:21:07) Ez hihetetlen. Tényleg fantasztikus.
  """

Új hozzászólás Aktív témák