Itt a bizonyíték - mostantól jöhetnek a csúcsjátékok is a böngészőkbe

Itt a bizonyíték - mostantól jöhetnek a csúcsjátékok is a böngészőkbe
2017-03-08T08:33:32+01:00
2017-03-11T18:09:54+01:00
2022-10-19T18:15:33+02:00
  • Nem hiszem' hogy felemás megoldást szeretnének. A komplett virtuáli gépet akarják GC-vel együtt implementálni. 
    Valami ms blogon olvastam, a SL jövőjére adott kérdésre, hogy ez kiváltaná az egészet, hiszen a keretrendszer bytekódja is egyszerűen letölthetöek igy.
    Mutasd a teljes hozzászólást!
  • Kicsit tömören írtad, úgyhogy akár totál félre is érthettem.
    Ha egy WebAssembly-ben implementált MSIL (talán most is ez a neve) értelmezőről van szó, az GC nélkül eléggé félmegoldás, hiszen a GC-s memóriakezelés megvalósításához mindent a JavaScript heap-jén kell tárolnia. Vagy az értelmezőhöz kell csapni valami GC-t, ami jelenleg kizárólag green threadként bírna létezni, ekkor kezd lassulni a dolog (meg hízik is).
    Az értelmező maga nem kell, hogy nagy legyen, a kezdeti LEGO-kockás JVM valami 10 kilobyte volt.
    Mutasd a teljes hozzászólást!
  • Mintha olyat olvastam volna, hogy pl. a ms tervezné, hogy a bytekód értelmezőt meginálják WA-ben is... innen meg egy új világ nyílik.
    Mutasd a teljes hozzászólást!
  • A JS megmarad annak, amire kitalálták. Script nyelvnek.

    Ez most egy korrekció!

    A JS túlnőtte magát (egy kialakult monopolhelyzet miatt) és olyasmikre használják, amire nagyon nem való.
    Ezt a helyzetet teszi rendbe a webasszembly. Két versenyző van a pályán, de mindkettőnek meg van a helye, ami nagyon különbözô.
    Mutasd a teljes hozzászólást!
  • Lefordul, természetesen kötöttségekkel a forrásban.
    Mutasd a teljes hozzászólást!
  • Eredetileg az Unreal motorját is csak az Unreal használta. A xenko-nak amúgy az a baja (ami a wave-nek is) hogy senki nem tudja hogy milyen licensszel jön ki, és mennyiért. Másrészt a játékmotorok piacára (még az ingyenesekre is) elég nehéz ma már bekerülni. Ott van Pl. a unity3d a kisebb cégeknek ingyen, ott van az ogre, ott van az én kedvencem az urho3d (urhosharp), a godot, ott van 2D-re a libgdx, stb.
    Mutasd a teljes hozzászólást!
  • Teccikérteni?

    Jó, jó. Bár az asm.js egy borzalmas hack ha forráskódban nézed, végeredményben igazad van: tipikusan WebAssembly kódot sem fog senki sem kézzel írni. Különösen, hogy jelenleg még nincs szöveges változata, csak a bináris reprezentáció teljes.

    Amit viszont az átvitelről írsz, az eléggé off, és nem is teljesen helyes:

    Erről szól a HTTP/2, erről szól az aszinkron erőforrásbetöltés, erről szól a gzip-elt átvitel, erről szólnak a dinamikusan betöltött képek, erről szólnak az above the fold inline stílusok, erről szól a minification, erről szól a tartalomtárolás a localStorage-ben, stb. Ezekre a dolgokra a korral haladó webfejlesztők mindig is átírták a dolgaikat

    Ezeknek a technológiáknak egy része ideális esetben teljesen transzparens. Pl. egy webes alkalmazásnak nem kell tudnia sem a HTTP verzióról, sem a Content-Encoding-ról. A többi meg a meglévő kód kisebb-nagyobb változtatásaival elérhető. Ehhez képest ha van egy JavaScript alkalmazásod, és profitálni szeretnél a WebAssembly-ből, akkor át kell írni egy másik nyelvre.

    Amúgy nem teljesen specifikáltuk, hogy miről is beszélgetünk. Egy szituáció, ha van egy kész webes alkalmazás, és azt kéne megtáltosítani, és egy másik szituáció, ha egy meglévő "natív" kódbázist kéne megwebesíteni. És szerintem itt is szétválik, hogy az ténylegesen natív-e (hagyományosan C/C++, akár assembly), vagy menedzselt, VM-ben futkosós (JVM, .NET).
    Szerintem:
    - webalkalmazás táltosítás: asm.js-re fokozatosan át lehet térni, akár kézzel is, WebAssembly-re viszont nem nagyon, csak ha újraírja az illető a kódot valamilyen "ténylegesen natív" nyelven. Én erről beszéltem, hogy ez túl nagy meló ha csak az alkalmazás indulásakor számít az eredménye
    - "ténylegesen natív" kód: becsomagolható mindkettőbe (WebAssembly, asm.js), a méretük eléggé el fog térni, ezt említett
    - VM-es nyelv: szerintem itt a WebAssembly nem játszik, most még biztos nem. Az asm.js maga is JavaScript kód lévén közvetlenül tud támaszkodni a JavaScript környezetre, illetve a VM-es nyelvekben elvárt GC-zést is a JavaScript motorra bízhatja. A WebAssembly is pont ezt kell, hogy tegye, viszont így a saját "gyors" memóriáját alig tudja használni, a lokális/stack változókon kívül mindent a JavaScript heapen kéne foglalnia, és különféle varázslatokkal elérnie. Egyébként ez az általad linkelt GC integráció után sem sokban változna, csak a WebAssembly kódban fogott referenciák elegek lesznek ahhoz, hogy a GC ne dobjon ki valamit a JavaScript heapről - most ehhez még külön wrapper kell.
    Mutasd a teljes hozzászólást!
  • Majd ha videó helyett tartalom lesz beágyazva a cikk tetejére
    Mutasd a teljes hozzászólást!
  • Ott van a link a kipróbálható demóra. Firefox 52 vagy Chrome 57 kell hozzá.
    Mutasd a teljes hozzászólást!
  • Meg vagyok győzve. Ja, nem. Majd ha videó helyett tartalom lesz beágyazva a cikk tetejére, és látom vállalható FPS-sel futni, akkor majd eltűnődöm, hogy lehet-e a dolognak létjogosultsága. Addig maradok 

    irigy kritikus
    Mutasd a teljes hozzászólást!
  • Fejlesztői szemszögből volt szó eddig egyébként arról, hogy miért érdemesebb a C++ helyett egy modernebb nyelvet használni engine íráshoz, szó nem volt játék logika írásáról.

    A C++ (11-17) is egy modern nyelv.
    Mutasd a teljes hozzászólást!
  • Fejlesztői szemszögből volt szó eddig egyébként arról, hogy miért érdemesebb a C++ helyett egy modernebb nyelvet használni engine íráshoz

    Nem. Arról volt szó, hogy szerintem miért nem igaz ez az általad kijelentett állítás.

    Én azzal érveltem, hogy ha C# valóban egyértelműen jobb lenne ilyen célra, mint ahogy állítod, akkor a piacon ezek a megoldások dominálnának, mint ahogy a web-en sem a C++-os CGI-s megoldások dominálnak, nem véletlenül.

    Aha és te már ebből a két forrásfile-ból már át is látod az egész architektúrát és már le is vontad a megfelelő következtetéseket

    Te hoztál fel két konkrét engine-t, hogy hasonlítsam már össze őket és vonjam le a következtetéseket. Az általad említett motor architektúráját nyilvánvalóan ugyanúgy nem láttam volna át pár forrás kód alapján. Továbbá a fejlesztők által választott architektúra implementációs kérdés, nem azért olyan amilyen, mert az adott nyelven csak így lehet implementálni.

    Hogy mi a következetés? Nagyjából ez.
    Egyes forrásokba belenézve a C++ nem tűnik egy gányolt bloated átláthatatlan megoldásnak egy hasonló C# kód mellett.
    Mutasd a teljes hozzászólást!
  • Közben kijött a Chrome 57, benne van a bekapcsolt WebAssembly. Működik vele a cikkben linkelt Zen Garden demó!
    Mutasd a teljes hozzászólást!
  • Rendben, tehát jobb. Market share-en miért nem látszik? Unity3D, Unreal, Cocos2d, CryEngine, Ogre.. tarolnak, pedig elavult rossz átláthatatlan, tesztelhetetlen C++-ban íródtak :(

    Most írom le harmadjára, te is valami alternatív dimenzióban élsz?

    olyan C# motort, amit a fejlesztőjén kívül más is használna még nem láttam

    Vagyis attól, hogy valamit egy hatékonyabb, modernebb  nyelven írnak (legyen az C#, vagy akár JS, Rust, akármi) még nem jelenti azt, hogy a felhasználók szemszögéből is népszerűbb lesz. Annál is inkább, mivel felhasználói oldalon újabban már vizuális programozás formájában jelenik meg maga a "kódolás", vagy legalábbis valamilyen teljesen más nyelven jelentkezik az. Fejlesztői szemszögből volt szó eddig egyébként arról, hogy miért érdemesebb a C++ helyett egy modernebb nyelvet használni engine íráshoz, szó nem volt játék logika írásáról.

    Nem látok rá az Unreal kódjára, de belenéztem a CryEngine-be és a Xenko forrásokba. Igen más

    Aha és te már ebből a két forrásfile-ból már át is látod az egész architektúrát és már le is vontad a megfelelő következtetéseket, vagyis?
    Mutasd a teljes hozzászólást!
  • Konzolos bongeszokben (legalabbis az xboxosban) tiltott a JIT a link alapjan. Te azt irtad konzolon tiltott a JIT. Az teljesen mast jelent. Probal meg erthetobben fogalmazni... Nehez erteni, hogy mit irsz, ha a fele csak a te fejedben letezik.
    Mutasd a teljes hozzászólást!
  • Attól eltekintve, hogy eddig senki nem beszélgetett az asm.js-ről (csak megemlítetted egyszer, én meg idéztem),

    Aha. Tehát mégis arról (is) beszéltünk. Legalább elismerted.

     a) a böngészőnek támogatnia kell, b) a kódban meg egy prológgal deklarálni kell a használatát.

    És? Ez mi mellett vagy ellen érv? Ha semmi mellett/ellen, akkor minek írod le?

    Az egyrészt nem én voltam,

    Senki nem mondta, hogy te voltál.

    másrészt ha megnézel egy mai PC-s játékot, látni fogsz kb. 10-20 megányi exe-t meg dll-t, és 5-30 gigányi grafika-hang-mozi adatot. A töltési-feldolgozási idők egyszerűen nem a programkódról szólnak

    Rajtad kívül senki nem mondta, hogy arról szólnának.

    Szóval azt írtam, hogy ha kizárólag az indulásról szólna a WebAssembly, akkor nem érdekelne senkit

    Ami ugye hülyeség, hiszen az indulási idő éppen úgy fontos, mint a futási sebesség.

    Mivel létezik AOT, stb. ezért senki nem fog nekiállni átírni a kódját valami másra, csak hogy másodperccekkel hamarabb induljon, de utána a következő órákban ne legyen gyorsabb semennyivel.

    Dehogynem. Hiszen évtizedek óta ezt csináljuk, hogy folyamatosan, apránként faragunk le a letöltési és az oldalmegjelenítési időkből is. Erről szól a HTTP/2, erről szól az aszinkron erőforrásbetöltés, erről szól a gzip-elt átvitel, erről szólnak a dinamikusan betöltött képek, erről szólnak az above the fold inline stílusok, erről szól a minification, erről szól a tartalomtárolás a localStorage-ben, stb. Ezekre a dolgokra a korral haladó webfejlesztők mindig is átírták a dolgaikat, illetve adoptálták őket új projektjeikben, mert ezek segítségével lehetett egyre tovább és tovább javítani a felhasználói élményt.

    Na, akkor most végülis igaz, csak azért kellett az elejére egy tagadás is?

    Nem, nem igaz, hogy különbség lenne ebben az eddigi technológiák (pl. asm.js) és a WebAssembly között.

    Rajtad kívül mindenki arról (hagyományos JavaScript kód) beszél ám.

    Nem, nem csak én beszélek róla, hanem kettőnk közül csak én vagyok az aki tudja, hogy miről beszél. Én tudom, hogy az, amit te a WebAssembly újdonságának tulajdonítasz, azt már az asm.js is tudta. Te nem tudod, ezért azt gondolod, hogy amikor erről a dologról (ti. hogy "mindennek előre ismert a helye és a típusa") beszélsz, akkor csak a WebAssembly-ről beszélsz, pedig valójában az asm.js-ről is. Tehát valójában mindketten az asm.js-ről is beszélünk - csak te ezt nem tudod, mert azt hiszed, hogy annak nem sajátossága az, amiről beszélsz. Miközben de. Teccikérteni?

    Szerencsére ez nem így van. Mármint beszélsz róla, de a GC egy 0 csillagos prioritású fejlesztési pont, és elég hasznos ötletek előzik meg (mint többszálúság meg SIMD támogatás).

    Ehhez képest a GC-nek már külön oldala van a WebAssembly fejlesztési tervei között, míg az SIMD-ről konkrétan csak mindösszesen két mondat van benne. Nem mintha hogy ha a SIMD-támogatás tényleg előbbre járna (mint ahogy nyilvánvalóan nem teszi ezt), az bármiben is invalidálná az általam a GC-vel kapcsolatosan írtakat. Csak mondom.
    Mutasd a teljes hozzászólást!
  • hogyan is működik a JavaScript és az asm.js, illetve a WebAssembly kódok futtatása a böngészőben.

    Attól eltekintve, hogy eddig senki nem beszélgetett az asm.js-ről (csak megemlítetted egyszer, én meg idéztem), az mellesleg úgy működik a böngészőben, hogy a) a böngészőnek támogatnia kell, b) a kódban meg egy prológgal deklarálni kell a használatát. Ha nincs deklarálva, akkor jöhet a "majd a browser egy idő után rájön" rész.

    Főleg akkor, amikor valaki pont azon az alapon kritizál egy adott futtatóplatformot, hogy - legalábbis szerinte - irtó sokat kellene várni ahhoz, hogy elinduljon a játék.

    Az egyrészt nem én voltam, másrészt ha megnézel egy mai PC-s játékot, látni fogsz kb. 10-20 megányi exe-t meg dll-t, és 5-30 gigányi grafika-hang-mozi adatot. A töltési-feldolgozási idők egyszerűen nem a programkódról szólnak, ha full szkript lenne szöveges formában, akkor sem. A hivatkozott valaki szinte biztos, hogy erről beszélt.

    csak nem tudod, hogy így kellene hívni őket.

    Személyeskedsz, plusz lenézed a másikat. Ez még akkor is primitív viselkedés volna, ha igazad lenne. De nincs. Szándékosan az indulást írtam körül, ami bár beleszámít az összesített futásidőbe, normál esetben annak elenyésző része.

    Ugye ez sem igaz. Mert a valóság az, hogy konkrétan rengeteget foglalkoztak ezzel már akkor is, amikor a WebAssembly a képben sem volt. Mármint azzal, hogy gyorsabb legyen az indulás is. Erről szól a többszálon futó ahead-of-time fordítás, ami már évek óta működik a JavaScrit kódok esetében is.

    Ugye szándékosan félremagyarázod. Vagy legalábbis én azt hiszem, de persze hülyének is nézhetlek, ha az jobban fekszik. Szóval azt írtam, hogy ha kizárólag az indulásról szólna a WebAssembly, akkor nem érdekelne senkit - pont azért, mert amiket sorolsz már vannak. Mivel létezik AOT, stb. ezért senki nem fog nekiállni átírni a kódját valami másra, csak hogy másodperccekkel hamarabb induljon, de utána a következő órákban ne legyen gyorsabb semennyivel.

    Ez megint nem igaz. Illetve annyira igaz, mint amennyire az asm.js-re is igaz.

    Na, akkor most végülis igaz, csak azért kellett az elejére egy tagadás is? Lehet, hogy át kéne írnom az előző bekezdést. Rövidebb is lenne.

    Ez amiről beszélsz legfeljebb a hagyományos JavaScript kód - de még ott is helyzetfüggő a dolog.

    Rajtad kívül mindenki arról (hagyományos JavaScript kód) beszél ám. A WebAssembly-vel hasonlítjuk össze a teljesítményét. Minden mást te rángattál elő személyesen.

    Arról, hogy a WebAssembly következő kiadásában ráadásul már GC támogatást is akarnak rakni a futtatóplatform szintjébe, már nem is beszélek.

    Szerencsére ez nem így van. Mármint beszélsz róla, de a GC egy 0 csillagos prioritású fejlesztési pont, és elég hasznos ötletek előzik meg (mint többszálúság meg SIMD támogatás).


    OFF: valami nem kóser a szerkesztővel, nem nagyon lehet benne idézet+nemidézet blokkokat egyszerre törölni (írtam még sokat, csak letöröltem), illetve pl. amikor idézetet beszúrok, lesz előtte egy üres sor, ahol a Delete gomb nem csinál semmit (de a kódszerkesztőben már nincs ott, és onnan visszatérve eltűnik). Chrome legfrissebben néztem.
    Mutasd a teljes hozzászólást!
  • Egyrészt nem hiszem, hogy tudnád, hogy mi a piaci részesedése ezeknek a motoroknak


    Természetesen célirányos google találtok alapján írtam a kijelentésem. Több felmérést és kimutatást lehet találni, persze egyik sem a legfrissebb és a jelenlegi állapotot mutatják, de az alapvető piaci részesedések láthatóak rajtuk. Van találtat, ami kimondottan egy adott platform top 100 játékát vette górcső alá, van ahol csak megkérdezték a fejlesztőket, stb..
    De egy gyorskeresés alapján nem találtam egyetlen olyan oldalt sem, amely pl a Xenko-t egy szinten említette volna a Unity-vel, vagy az UE-vel (ha említette egyáltalán, mert a többségben ki sem emelik a Xenko-t).
    Ez alapján szerintem bőven lehet reális következtetéseket levonni pl a Xenko és a Unity, vagy UE elterjedése között.

    Varázs szavak amiket használtam: '3d engine market share' 'most popular game engine'
    Mutasd a teljes hozzászólást!
  • Rendben, tehát jobb. Market share-en miért nem látszik?
    Unity3D, Unreal, Cocos2d, CryEngine, Ogre.. tarolnak, pedig elavult rossz átláthatatlan, tesztelhetetlen C++-ban íródtak :(

    Egyrészt nem hiszem, hogy tudnád, hogy mi a piaci részesedése ezeknek a motoroknak az összes játékmotorok között - de persze mondd, ha van tényszerű adatot erre vonatkozóan! Illetve piaci részesdésből is van többféle, és azt lehet pl. a motort licencelő fejlesztőcégek száma, a velük dolgozó fejlesztők száma, a velük készült játékok felhasználóinak száma, a velük készült játékok eladott darabszáma, a velük készült játékok eladási összértéke, stb. alapján számolni, amikből mind más eredmények és sorrend jönnének ki. És akkor olyan szubjektív szempontok szerint sorrendről, mint hogy a fejlesztők mennyire vannak megelégedve vele, vagy hogy a velük készült játékok mennyire bizonyulnak stabilnak, még nem is beszéltem (pedig ezek is lehetnek indikátorai a motor átláthatóságának, tesztelhetőségének, stb.)

    Másrészt teljesen nyilvánvaló az is, hogy manapság a játékmotorok esetében az, hogy maga a motor kódja miben íródott legjobb esetben is csak egy sokadlagos faktor - az meg pláne az, hogy mennyire átlátható vagy tesztelhető a kódja. Mert hogy a motorok felhasználó közül a legtöbben nem kotorásznak a kódjában, még felszínesen sem. A végfelhasználók, a játékosok ugye biztosan nem teszik ezt, de a köztes felhasználók, a játékfejlesztők közül is a legtöbben nem nagyon nézegetik a motor kódját, hanem legjobb esetben is csak kiegészítéseket fejlesztenek hozzá - de leginkább nem is kódolnak, hanem csak az adott motorhoz készült interaktív tervezőeszközökkel dolgoznak. Még az úgymond shader-programozók sem a motor nyelvén írják a kódjaikat, hanem egy attól független vagy legfeljebb azzal csak marginálisan összefüggésbe hozható nyelven. Így legtöbbjüknek nem tudja és nem is érdekli, hogy a motor kódja mennyire átlátható, elavult vagy tesztelhető.

    Ezzel egyébként nem akarok C++ átláthatóság és tesztelhetőség kérdéskörben állást foglalni. Csak annyit mondok, hogy az, amire hivatkozol, hogy ti. az általad ismert vagy esetleg akár reprezentatív értelemben is legismertebb, illetve legnagyobb játékmotorok C++-ban íródtak, semmit nem mond el sem a nyelvről, sem ezen motorok kódjának minőségéről, sem abszolút, sem relatív értelemben.
    Mutasd a teljes hozzászólást!
  • Dehogynem.

    De nem. Csak elég nyilvánvalóan félreértésben vagy azt illetően, hogy hogyan is működik a JavaScript és az asm.js, illetve a WebAssembly kódok futtatása a böngészőben.

    Ezek igaz és lényegtelen előnyök. Mert egyszer érvényesülnek a futtatás kezdetekor

    Ez persze nem igaz. Mármint az, hogy a futás kezdetekor érvényesülő előny lényegtelen előny lenne - mert, hogy persze hogy lényeges előny. Főleg akkor, amikor valaki pont azon az alapon kritizál egy adott futtatóplatformot, hogy - legalábbis szerinte - irtó sokat kellene várni ahhoz, hogy elinduljon a játék. Itt pedig ugye pont ez történt. Tehát adott esetben ez sokkal lényegesebb előnye, mint a futásidejű előnyök, amiről beszélsz, csak nem tudod, hogy így kellene hívni őket.

    Ha ennyi lenne a történet a JIT-elt JS-hez képest, senki nem foglalkozna vele.

    Ugye ez sem igaz. Mert a valóság az, hogy konkrétan rengeteget foglalkoztak ezzel már akkor is, amikor a WebAssembly a képben sem volt. Mármint azzal, hogy gyorsabb legyen az indulás is. Erről szól a többszálon futó ahead-of-time fordítás, ami már évek óta működik a JavaScrit kódok esetében is.

    Stabilan viszont pont azért lehet gyorsabb a WebAssembly-ből fordított kód, mert mindennek előre ismert a helye és a típusa.

    Ez megint nem igaz. Illetve annyira igaz, mint amennyire az asm.js-re is igaz. Ott is úgymond "mindennek előre ismert a helye és a típusa" . A WebAssembly tehát ahhoz képest ezen a téren nem hoz előrelépést, nem ettől jobb és gyorsabb - ha és amikor az. Mert bizony jelen állapotában az is előfordul, hogy nem az.

    A típusos tömbök elemei tényleg ismert típusúak, de a tömb objektum maga egy közönséges JavaScript változó marad, amire egy metódust hívsz ("Mi lehet az az x? Ja, egy Uint32Array! Van-e neki xy metódusa? Van. Hívjuk meg! Jó!")

    Nem, illetve erre megint ugyanaz igaz, mint az asm.js kódokra. Ti. hog egy asm.js-t támogató JavaScript-motor éppen úgy pontosan tudja, hogy egy UInt32Array az egy speciális szerkezet, és ennek megfelelő kódot generál mögé - nem pedig generikus tömbként kezeli.

    hogy kijöjjön belőle a fix típusú akármi, és a futtatókörnyezet persze "rájöhet", hogy mondjuk egy ciklusban mindig ugyanazt a tömböt piszkálja valaki ugyanazzal a metódussal, és akkor ezt az elérést rövidre lehet zárni, de már megint itt van a menet közben varázslunk rész.

    Megint nem. Ez amiről beszélsz legfeljebb a hagyományos JavaScript kód - de még ott is helyzetfüggő a dolog. Ti. hogy pl. csak eljárások belépési pontjain átadott paraméterekre vagy globális változókra igaz ez - de pl. függvényen belüli lokális kód esetében részben vagy teljesen simán generálható úgymond statikus kód is mögé.

    Ugyanakkor asm.js esetén már abszolút nem igaz, mert ott nincs szükség ezekre a futásidejű ellenőrzésekre. Tehát ehhez képest, illetve ebből a szempontból a WebAssembly nem előrelépés az asm.js-hez képest, nem ezért találták ki, és nem ez a legnagyobb előnye.

    Arról már nem is beszélek, hogy már eleve mazsolázgatás mindig csak olyan kódokról, illetve kódrészletekről beszélni, amik esetében "mindennek előre ismert a helye". Mert, hogy ilyen a való életbeli programok esetében jellemzően csak a kódok csak töredéke, még akkor is, ha az adott program úgymond statikus nyelven íródott. Lásd bázistípusú referenciák, dinamikus castok, virtuális metódustáblák, stb.

    Még a GC-vel is meg kell beszélni a dolgot, nehogy odébbtegye a tömböt miközben az (n)agyonJIT-elt kód dolgozik rajta.

    Ez megint nem így működik, illetve az, hogy van -e vagy szükséges -e a GC, a programozási paradigmától függ, amiben a program íródott. Ezzel összefüggésben attól, hogy jelenleg pl. a WebAssembly-ben nincs GC, a rá íródott programban még simán lehet - csak egy magasabb szinten implementálva. A másik oldalon egy JavaScript program is lehet olyan, hogy a GC-nek semmit sem kell csinálnia a futása során.

    Arról, hogy a WebAssembly következő kiadásában ráadásul már GC támogatást is akarnak rakni a futtatóplatform szintjébe, már nem is beszélek.
    Mutasd a teljes hozzászólást!
  • [LC:] A webassembly lényege pont a statikus típuskezelés, ettől gyors.

    Ez nem a lényege, és nem ettől gyorsabb, mint az eddigi technológiák.

    Dehogynem.

    Hanem [...] bináris reprezentáció [...] gyorsabban letölthető, kisebb helyet foglal, gyorsabban értelmezhető [...] gyorsabban generálható mögé tárgykód. Ennyi az előnye a WebAssembly-nek pl. az asm.js-hez képest.

    Ezek igaz és lényegtelen előnyök. Mert egyszer érvényesülnek a futtatás kezdetekor, gyakorlatilag nem is annak a részeként (mondjuk kiteszek egy splash screent, amíg a wasm kód elkészül). Ha ennyi lenne a történet a JIT-elt JS-hez képest, senki nem foglalkozna vele.
    Stabilan viszont pont azért lehet gyorsabb a WebAssembly-ből fordított kód, mert mindennek előre ismert a helye és a típusa. Dinamikus típusok meg GC-s memóriakezelés esetén erre csak fokozatosan "rá lehet jönni", menet közben, extra erőforrások ráfordításával - és a végén azért itt-ott maradhat benne egy kis "mivanha" kód. Plusz az egész nyelv általában assemebly-szerű, azaz processzor-barát.

    [...] illetve ezek JavaScript-ben is megvalósíthatók, illetve részben megvalósításra is kerültek (pl. UIntXXArray és FloatXXArray típusok). A WebAssembly tehát nem ezektől lesz gyorsabb az asm.js-nél, illetve a sima JavaScript-nél. [...]

    A típusos tömbök elemei tényleg ismert típusúak, de a tömb objektum maga egy közönséges JavaScript változó marad, amire egy metódust hívsz ("Mi lehet az az x? Ja, egy Uint32Array! Van-e neki xy metódusa? Van. Hívjuk meg! Jó!"), hogy kijöjjön belőle a fix típusú akármi, és a futtatókörnyezet persze "rájöhet", hogy mondjuk egy ciklusban mindig ugyanazt a tömböt piszkálja valaki ugyanazzal a metódussal, és akkor ezt az elérést rövidre lehet zárni, de már megint itt van a menet közben varázslunk rész. Még a GC-vel is meg kell beszélni a dolgot, nehogy odébbtegye a tömböt miközben az (n)agyonJIT-elt kód dolgozik rajta.
    Mutasd a teljes hozzászólást!
  • egy jóval átláthatóbb, rugalmasabb, könnyebben fejleszthető, tesztelhető es nem utolsó sorban scriptelhető architektúrát nyerünk.

    Rendben, tehát jobb. Market share-en miért nem látszik?
    Unity3D, Unreal, Cocos2d, CryEngine, Ogre.. tarolnak, pedig elavult rossz átláthatatlan, tesztelhetetlen C++-ban íródtak :(

    Nézd meg a Xenko és az Unreal kódját, hogy közel azonos engine, editor és script mellett melyik a tömörebb, szebb, átláthatóbb.

    Nem látok rá az Unreal kódjára, de belenéztem a CryEngine-be és a Xenko forrásokba. Igen más.
    xenko/sources/engine/SiliconStudio.Xenko.Engine/Audio/AudioEmitterProcessor.cs
    CRYENGINE/Code/GameSDK/GameDll/Audio/AudioSignalPlayer.h
    Mutasd a teljes hozzászólást!
  • ... erre inkabb nem irok semmit sem ...
    Mutasd a teljes hozzászólást!
  • Nézz fel a xenko weblapjára. Az tisztán C#-ban van, és elég látványos kis demója van.

    Tényleg? Pont azért írtam korábban, hogy:

    olyan C# motort, amit a fejlesztőjén kívül más is használna még nem láttam

    aztán pedig ezt

    Azért kéne C#-ra átírni, hogy amiket leírtál ne is létezzen. Másrészt egy jóval átláthatóbb, rugalmasabb, könnyebben fejleszthető, tesztelhető es nem utolsó sorban scriptelhető architektúrát nyerünk. Nézd meg a Xenko és az Unreal kódját, hogy közel azonos engine, editor és script mellett melyik a tömörebb, szebb, átláthatóbb.

    Te amúgy valami párhuzamos világbeli fórumot olvasol, vagy mi?
    Mutasd a teljes hozzászólást!
  • Nagy hirtelen ezt a linket találtam:

    TwitterEbben épp az Xbox One JIT-ről van szó, hogy nincs a böngészőben.
    Mutasd a teljes hozzászólást!
  • Nem szó szerint azt írtam: "Tehát ha a Snowdrop C/C++-ban van írva, akkor az lefordul WebAssembly-re.". Feltételes módban írtam.
    Mutasd a teljes hozzászólást!
  • Linket, barmifele referenciat. Ne csak annyit, hogy "ez mindig is igy volt".

    Amugy nem, ettol meg nem lehet kvazi ingyen fejleszteni konzolra.
    Mutasd a teljes hozzászólást!
  • Te felelotlenul azt allitottad, mivel a snowdrop c++-van van irva, ezert konnyen lefordul webasm-re. Ez igy egyaltalan nem igaz. 

    Tehát ha a Snowdrop C/C++-ban van írva, akkor az lefordul WebAssembly-re.

    A programozas nem igy mukodik.
    Mutasd a teljes hozzászólást!
  • Amikor én néztem a konzolos fejlesztéseket, akkor a Xbox és PS beépített böngészőkben nem volt JIT, emiatt lassú volt a JavaScript is. A magyarázat meg az volt, hogy nem érdekük a konkurencia. Ezt a gondolatot vittem tovább, hogy a WebAssembly esetén sem fogják engedni a JIT-et. Amit el tudok képzelni az az, hogy ez azóta megváltozott. Nem vagyok up-to-date PS4 és Xbox One esetén. 

    Egy gyors google kereséssel csak egy twitter üzenetet, meg PS4 konzol hack oldalt találtam a témával kapcsolatban. Azok szerint még mindig nincs JIT beépített böngészőkben sem.

    TwitterValószínű amúgy ha elkezdenének terjedni a WebGL, WebGPU játékok, akkor azokat is letiltanák konzolról.
    Mutasd a teljes hozzászólást!
  • Szerintem kevered a szezont a fazonnal. A JIT kapcsán ami tilos a konzolokon, illetve a zárt ekoszisztémákban (bár ennek is csak marginálisan van köze a JIT-hez) olyan értelmező vagy futtatóplatform létrehozása, ami képes külső forrásból tetszőleges kód generikus letöltésére és futtatására. Ez valóban nem támogatott, pont azért, hogy ne lehessen a konzol, mint zárt platform falait megkerülni.

    Ugyanakkor ennek semmi köze nincs ahhoz, hogy a konzolba a gyártó által - vagy harmadik felek által egyedi licenc alapján - épített technológiák használnak -e JIT-et vagy sem. Tehát pl. ettől még az Xbox-on alapból megtalálható futtatóplatformok (mint pl. a gyári böngésző is) nyilván használhatnak és használnak is JIT-et.

    Az már más kérdés, hogy a Microsoft vajon elérhetővé teszi -e akár a WebGL 2-t, akár a WebAssembly támogatást az Xbox One-on. Mert ez tényleg nem áll érdekében, és mert ezeket a konzolon tényleg csak a platform falainak megkerülésére lehetne használni, egyéb "legitim" felhasználási módjaik ott nem nagyon lehetnek.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd