Szupergyorssá teszi a JavaScript-WebAssembly hívásokat a legújabb Firefox
2018-10-10T09:35:09+02:00
2018-11-05T22:02:02+01:00
2022-07-19T00:16:13+02:00
  • Bár a JavaScript rutinok WebAssemby kódokból történő hívása már eddig is gyors volt (0.6 másodperc alatt 100 milliót lehetett végrehajtani belőlük egy átlagos gépen), a másik irány igen szűk keresztmetszetet képezett. A JavaScript-ből a WebAssembly rutinok meghívása ugyanis ennél több, mint tízszer több időt (5.5 másodpercet 100 millió híváshoz) igényelt.

    Milyen számítás szerint "több, mint tízszer több" az 5.5 a 0.6-nál?
    Mutasd a teljes hozzászólást!
  • Nemrég én is ts-t gányoltam, angularral. A node az mondjuk tényleg kellett neki, de azon túl, hogy induláskor kellett pár másodperc a fordításhoz, utána már nem igazán vettem észre hogy fordít. Csak mentettem, aztán egy tab a vs code-ból a böngészőbe, és már ott is volt az eredmény.
    Mutasd a teljes hozzászólást!
  • Ha a megfelelő toolok rendelkezésre állnak, nem kéne észrevenned a fordítást.

    Valóban nem kell, épp TS-t gányolok és mentés után pár másodperccel újratölti a böngésző. De ehhez azért letöltődött 190 megányi node.js+Python csoda, ami nélkül eddig egész jól elvoltam.
    Amúgy meg igen, még Sinclair-Commodore korszakban kezdtem, a "Perils of Java schools"-t is ismerem. És a WebAssembly-vel szemben sincs kifogásom, foglalkoztam már vele behatóbban.

    hogy tisztán TypeScript kódot tud fordítani, úgy működhet.

    Hello World-től felfele egyáltalán nem biztos, hogy ilyen kód tényleg létezik, de a TypeScript maga is dinamikus nyelv, és saját maga deklarálja, hogy minden JavaScript kód érvényes TypeScript. A típusokkal is elég nagy varázslatokat lehet azért csinálni, és persze az egész menedzselt memóriában történik.
    Mutasd a teljes hozzászólást!
  • Ha a megfelelő toolok rendelkezésre állnak, nem kéne észrevenned a fordítást.
    Ha foglalkoztál alacsony színtű nyelvvel, tudod mekkora kín egyáltalán a szöveg kezelése a gépnek (relatív, annál mindenképp több kín mint ha nem kell kezelni), nem hogy még egy engine-t futtatni, aminek a dolga, hogy ezeket dekódolja a számítógép számára. Mennyivel jobb, hogy a Javascript engine outputját kapja meg a böngésző egy az egyben.
    A JS továbbra is ott lesz, de az opció megvan, hogy használjunk mást, amit beláthatunk, hogy rontani nem ront a helyzeten, de javítani javíthat.

    A JS meg tudtommal nem TS kód, hanem a TS-ből lesz transpile-olva JS, hogy lehessen használni a böngészőben. Viszont akadálya nincs annak, hogy kihagyják a javascriptet a képből, és egyenesen lefordítsák wasm kódra. A Javascript fordítása már neccesebb, és a TypeScript-Javascript átjárhatóság borulna egy ilyen compiler esetén, de egy olyan kikötéssel, hogy tisztán TypeScript kódot tud fordítani, úgy működhet. Ez pedig lehetővé tenné akár az okosórákra vagy egyéb nagyon mini, gyengébb processzorú eszközökre történő webfejlesztést, és talán a webes közösség meg tudna győzni jó okosóra appokkal, hogy van értelme a terméknek.
    Mutasd a teljes hozzászólást!
  • Azt érzem, hogy a modern fordítóprogramok labdába sem rúghatnak. Az llvm például.

    Gyakorlatilag nincs WebAssembly LLVM nélkül. Szóval labdába rúg az, pont emiatt ne aggódj.
    Mutasd a teljes hozzászólást!
  • Ugyanakkor cikkeket nem lehet úgy kezdeni, hogy pl "Nem fogod elhinni, hogy milyen lassú volt a [tetszoleges JS technologia], egy legutobbi javítás ezen most változtat."

    A negativ dolgok jobb, ha a cikken belul vannak. pl "csúnya C++ köztes kódok" 

    Amúgy volt ott overhead boven, ha egy 3GHz-s valamin egy atlagos "rutinhívás" már nem 165 hanem 15 orajelig tart.
    Mutasd a teljes hozzászólást!
  • Azt érzem, hogy a modern fordítóprogramok labdába sem rúghatnak. Az llvm például.
    Mutasd a teljes hozzászólást!
  • Hogy lehet birkavesevel foldrengest megelozni?
    Mutasd a teljes hozzászólást!
  • Bámulatos hol tart már a tudomány. ?
    Mutasd a teljes hozzászólást!
  • Ez nagyon jó hír, csak mikor jönnek már ki végre azok a cuccok, amikkel dolgozni is lehet? Gondolok itt fejlesztőkörnyezetre, TS-wass fordítóra, különböző kód és vizuális library-kra üzleti alkalmazások számára.

    Hát, ezeknek kb. semmi köze a WebAssembly-hez, HTML5+CSS-hez nem azért nincsenek vizuális eszközök, mert 100 millió függvényhívás JavaScriptből WebAssembly-be 5 másodpercig tart (még ha komolyan is gondolnánk, hogy ez számít, a wasm-ból DOM manipuláció pont az ellenkező irányba történő hívásokat jelent, ami már eddig is gyors volt).
    Mutasd a teljes hozzászólást!
  • Ez nagyon jó hír, csak mikor jönnek már ki végre azok a cuccok, amikkel dolgozni is lehet? Gondolok itt fejlesztőkörnyezetre, TS-wass fordítóra, különböző kód és vizuális library-kra üzleti alkalmazások számára. (Jó, játékokhoz lehet, hogy van, de én konkrétan üzleti alkalmazáshoz használnám fel)
    Mutasd a teljes hozzászólást!
  • Õszintén szólva, nekem kb. tök mindegy, hogy azonnal fut-e, vagy 10 másodperccel a save gomb lenyomása után. Sima szövegszerkesztõben pedig nem fejlesztek kódot, max. vim-mel vagy VS Code-dal. Viszont egy ts->webasm valószínûleg gyorsabb végeredményt produkálna mint a natív js.
    Mutasd a teljes hozzászólást!
  • Azért jó lesz a kvantumszámítógép is valamire, elvégre a PHP-s backendnek is futnia kell valahol.
    Mutasd a teljes hozzászólást!
  • Eddig a JS is gyorsult állandóan 10, meg 100-szorosra, most meg már a webasm és a C++ miatt további 10 és 100 szoros gyorsulás van. A végén már nem is kell kvantumszámítógép se, elég lesz a böngésző is.
    Mutasd a teljes hozzászólást!
  • Figyelembevéve, hogy minden JS kód egyben TS kód is, egy ilyen fordítóban kell egy komplett JS fordító (a dinamikus "bármi megtörténhet"-re felkészítve), és még rá a típusok. Ehhez hozzávéve, hogy JS fordító már van a böngészőkben, pont a TS-be még külön energiát fektetni számomra meddő elfoglaltságnak tűnik.

    Nekem amúgy pont a fordítással van bajom, a web legjobb része a "közvetlenül futó" szöveges tecnológiák használata, akár közvetlenül a böngészőben, akár egy sima szövegszerkesztő segítségével. Ebbe a TS is meg a wasm is eléggé belerondít, az előbbi nyilvánvaló okokból, az utóbbi meg azért, mert csak a bytecode támogatását tették kötelezővé, pedig lenne szöveges is (Understanding WebAssembly text format - WebAssembly ).
    Mutasd a teljes hozzászólást!
  • (A 0,6 és az 5,5 kapcsolata szerintem közel tízszer több)
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Valaki csinálhatna már egy typescript->webassembly fordítót.
    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