A Google, a Microsoft és az ARM is tolni fogja a WebAssembly szekerét a jövőben
2021-05-03T08:35:54+02:00
2021-05-06T11:33:23+02:00
2022-07-20T10:26:49+02:00
  • A JS fordító is egy köztes reprezentációból dolgozik, nem a forrásból. Illetve elsőre nyilván abból, de később nem. Ez csak az indulást érinti, a futást nem. A típust pedig nem kell kitalálja, mert a típus már ismert, amikor a fordító kódot generál. Akkor kell csak type checket generáljon, ha nincs típus invariáns. Ilyen type checkekkel viszont tele van a C# kódodból generált programod is.
    Mutasd a teljes hozzászólást!
  • Meg hogy tervezetten asyncron és jövőálló?
    Mutasd a teljes hozzászólást!
  • Igen, a probléma az, hogy ezt ráadásul a cuccnak menet közben kell kisakkoznia. Szerintem mára önmagában az is lassít, hogy forrásból kell assemblyt gyártania egy már elõemésztett bytekód helyett, és erre jön még az rá, hogy ki kell hogy találja a típusokat.
    Mutasd a teljes hozzászólást!
  • Most nézem, hogy nekem is kellet fájl beolvasnom a kliensben és az InputFile.OnInputFileChange-ben visszakapott IBrowserFile interfész OpenReadStream eljárásával olvasom be. Gondolom, megvan az oka, hogy így kell olvasni és nem egy FilePath string-et kapsz az event-ben. Végül persze előfordulhat, hogy a háttérben ez valami JS kódot hív meg, de működik.

    async Task OnInputFileChange(InputFileChangeEventArgs e) { foreach (var imageFile in e.GetMultipleFiles(20)) { var stream = imageFile.OpenReadStream(maxSize); ...
    .
    Mutasd a teljes hozzászólást!
  • Az asm.js is js kód, csak olyan generált js kód, amivel leszűkítik a nyelvet a jól optimalizálható konstrukciókra, valamint megkerülik a JS-nek azt a problémáját, hogy nincs külön int és float típusa, így a fordító statisztika nélkül is tud olyan kódot generálni, ami intként kezel egy Number típust. És hát ez azért nem mindegy. De ez nem statikus vs dinamikus kérdés, hanem a fordító optimalizációja egy konkrét típusra (kód mintára gyakorlatilag), a típus nyelvbe történő bevezetése nélkül. Emellett a GC-t is eltüntették, ami szintén nem mindegy. Ahogy a WA esetén sincs GC. Illetve a WA-ban már vannak külön típusok intre és floatra.

    A lényeg, hogy egy adott kód optimalizálható "<type1,type2,...typeN>" konkrét típus N-esre, és így az adott kódnak több típushalmazra optimalizált változata is létezhet. És amik a típus invariánsokat tovább vihetik az onnan hívott függvényekre és így tovább. Hogy ezt mennyire és hogyan csinálja egy JIT, az nyilván implementáció és minta függő. 

    Ami a web esetén egy külön nehezítés, hogy azonnal reszponzív és gyors kódot kell tudni generálni, gyakorlatilag megfelelő statisztikák nélkül. Így valójában a JIT nem tud olyan jó felhasználói élményt adni, mint tud pl egy szerver alkalmazásnál (lásd pl Java, vagy C#), ahol a fordító az alkalmazás futásidejéhez képest (akár) relatíve rövid idő alatt elő tudja állítani az optimális kódot. Ezért weben kiemelten fontos a fordító nyelvi támogatása. Ez az, amiben a WA igazán előnyben lesz. Gyorsabban tud elkezdeni gyorsan futni a parser és elemzők elhagyásával, a streaming compilerével és egyéb hóbelevancaival.

    Meg persze egy JIT fordítónak jobban alá kell dolgozni, mint egy AOT fordítónak, és a front-end JS fejlesztők fókusza jellemzően nem ez.
    Mutasd a teljes hozzászólást!
  • Most viszont épp egy olyan ts kóddal szívok ahol a kódot eredetileg elkövetõ frontendes kollégák (akik még egy másik cég voltak egy másik országban) lépten-nyomon játszották ezt.

    Őszinte részvétem, de komolyan. Nálunk ilyen nincs. Nem alkalmazunk alkalmatlanokat mi sem :D . De azért ugye abban remélem egyetértünk ,hogy nem a technológiát minősíti az, ahogy felhasználják.  A kést sem gyilkolásra találták ki (remélem), mégis ölnek vele. Ettől még a kés egy jó szerszám. Ugyanez vonatkozik szerintem a programnyelvekre is. Lehet jól, és rosszul használni.
    Mutasd a teljes hozzászólást!
  • Azért anno az asm.js elég jó sebességnövekedést tudott produkálni csak azzal, hogy ott tényleg tudta a jitter hogy milyen típus várható, pedig a js-t már akkor is JIT-telték és a motorok már akkor is megpróbálták elõre kitalálni a típusokat.
    Mutasd a teljes hozzászólást!
  • Az a polgár azért egy olyan cégnél ahol C#-pal foglalkoznak kb. az elsõ pull request után új kihívásokat kellene hogy keressen. Most viszont épp egy olyan ts kóddal szívok ahol a kódot eredetileg elkövetõ frontendes kollégák (akik még egy másik cég voltak egy másik országban) lépten-nyomon játszották ezt.
    Mutasd a teljes hozzászólást!
  • Mert a C# ban nem tud visszaadni és fogadni az idóta ember  object-et , meg dynamic-ot , ugye ?   Aki idióta, az minden nyelven tud idióta lenni. Onnantól kezdve kenheted a hajadra a C#-ot :D
    Mutasd a teljes hozzászólást!
  • Pedig így van. Az egyértelmű, hogy a program minden pontján futás közben pontosan tudható minden változó aktuális típusa. Vagyis a JIT minden ponton fog tudni olyan natív kódot generálni és futtatni, ami a konkrét típusnak megfelelően van optimalizálva. Ami egy dinamikus nyelvnél különbség, hogy egy adott programrészlet esetén ugyanazon változó típusa lehet különböző két lefutás esetén. Elméletileg, de jellemzően nem különböző. Ez pontosan ugyanaz a probléma, ami polimorfizmusnál létezik, és ami esetben a JIT-ek statisztika alapján egy alábbihoz hasonló kódot szoktak belőle generálni:

    ha x változó típusa nem az elvárt // statisztika alapján feltételezett akkor ugrás nem elvárt típus szerint optimalizált kódra // ami lehet más típus szerint optimalizált kód // x változó típusa az elvárt // optimalizált kód az elvárt típus szerint...
    Az is egyértelmű, hogy típusvizsgálatot csak azokon a pontokon kell végezni, ahol megváltozhat a változó típusa. Tehát közel sem arról van szó, hogy úton-útfélen folyamatosan típusellenőrzéseket kell végezni ezzel lassítva a végrehajtást. Ha nincs olyan művelet, ami megváltoztathatja a változó típusát, akkor van egy típus invariáns, amit a fordító hatékonyan tud felhasználni. Tehát a JIT-elt JS kód is igen hatékonyan tud futni... 

    Azt egyébként le is írják több helyen, hogy a WA futási teljesítménye nem nagyon fogja számottevően elverni egy optimazált JS kód futási teljesítményét, és hogy más előnyei miatt lesz jó a WA.
    Mutasd a teljes hozzászólást!
  • Érdemes az idézett bekezdést végig is olvasni:

    An April 2021 study from Universität Stuttgart found that since then crypto mining has been marginalized, falling to below 1% of all WebAssembly modules gathered from a wide range of sources, also including the Alex top 1 million websites.
    Mutasd a teljes hozzászólást!
  • Csak a typescriptben semmi nem akadályozza meg a parasztot abban, hogy minden függvényben any-t használjon paraméterként is és visszatérési értékként is. Onnantól kezdve pedig a hajadra kenheted a typescriptet.
    Mutasd a teljes hozzászólást!
  • Ha ez így lenne, akkor anno a Mozilláék nem próbálták volna meg tolni az asm.js-t még a webassembly elõtt.
    Mutasd a teljes hozzászólást!
  • Ezért gyorsabb ma még a js: õt gépi kódra fordítja a futtató motor (már amennyire persze a dinamikus típuskezelése miatt lehet). De ha a blazor is "natív" webassemblyre fordít majd, akkor már be tudja elõzni a rendszer sebességben a javascriptet a statikus típuskezelés miatt.

    Erre azért nagy összeget ne tegyél fel. A JS JIT-nek pont ugyanannyi típusinformációja van, mint ami egy statikus nyelvről fordított WA kód futása esetén előáll. Hogy egy konkrét fordító ezt hogyan használja, az persze másik kérdés. De a WA előnye jellemzően nem a futási sebesség lesz.
    Mutasd a teljes hozzászólást!
  • Pontosan ezért használnak egyre többen Typescriptet. Amiben már kevés kivetni valót találsz, ha jól megnézet mit tud.  Angular fejlesztőként egyetlen , az általad említett problémával sem találkozom.
    Mutasd a teljes hozzászólást!
  • Ahogy Platón mondta, olyan mint a JavaScript csak hatékonyabb és kevésbé látható.
    Mutasd a teljes hozzászólást!
  • Ez lenne az, aminek a legfőbb alkalmazási területe a bitcoin-bányászat a kliensek böngészőjében?

    WebAssembly - Wikipedia
    Mutasd a teljes hozzászólást!
  • Ha napi szinten kell mások által nem túl jó minõségben gyártott kóddzsungelben eligazodnod, akkor kincset ér, ha tudod hogy egy adott függvény adott paramétereként adott típusú dolog jöhet és nem bármi. És nem 30 különbözõ helyen fog egy class példányosítása helyett random objektumokat kihányni magából a kód, amit aztán a függvényed megkaphat, vagy épp továbbít egy másik rendszernek ami csak néz hogy mi a fenét kapott, mert pityuka az egyik helyen úgy gondolta hogy szám helyett jó lesz propertynek a string is.
    Mutasd a teljes hozzászólást!
  • Nem az a cél, hogy a JS fejlesztők térjenek át C#-ra.
    Csinálják ha bírják idegekkel :)

    A cél, hogy a C# fejlesztőket ne kényszerítsük be a JS használatába.

    Járulékos haszon, ha a C# ökoszisztéma használható, sőt ez a legnagyobb gól.
    A szerver és kliens kód megosztható legyen, hogy pl. szövegformátumra alakítás (laza kapcsolat, annak minden előnyével, de hátrányával is!!!) kényszer legyen, mert könnyebb út.
    A legegyszerűbb példa a C/S kommunikációban közös osztályok használata és teljesen átlátszó adatátvitel, mindeféle konverziók nélkül.
    Mutasd a teljes hozzászólást!
  • Én is így értettem, hogy ha végre széles körben használható lenne, akkor utána már semmi értelme nem lenne js-t használni új projektekben.
    Nyilván a több év alatt elkészült több tízezer sornyi frontend kódokat nem fogja elkezdeni senki hirtelen webassembly-re átírni :D
    Mutasd a teljes hozzászólást!
  • Miért kéne leváltani a JS-t mindenáron? Úgy se fogjuk, mindenhol az van használva, nem éri meg átírni. Bőven elég, ha új fejlesztésnél azt választja ki a cég, ami igényeihez megfelel. És bizony rengeteg dolog van, amihez a Blazor is meg tud felelni. Ha egy technológia nem flele meg az igényeknek, hát nem kell azt választani. Ez igaz a JS-re is, nem véletlenül nem böngészőben írták a legkomplexebb GUI és elemző programokat.
    Mutasd a teljes hozzászólást!
  • No igen, ebben bízok én is, hogy a .Net 6-tal végre széleskörűen használható lesz. Mondjuk a belinkelt példa alapján az AOT-vel se lesz gyorsabb, mint a javascript, szóval erre írtam, hogy majd hiszem amikor látom, hogy milyen lesz a .net 6-os végeredmény.
    Az biztos, hogy nagyon biztató az irány, és ha a nagyok jobban beleállnak, netán a Webassembly megkapná azokat a futtatási elérési szinteket, mint a javascript, akkor már dobnám is ki az egész js tudásomat az ablakon, és végre el lehetne felejteni azt a kretén nyelvet.
    Mutasd a teljes hozzászólást!
  • Net5 is érezhetően gyorsult az elődhöz képest. Üzleti appokhoz már most is használható. Kép feltöltés/manipulációhoz/erőforrás igényes dolgokhoz vannak libek szép számmal, illetve a JS Interop sem ördögtől való. Tizen évvel ezelőtt normális JS Grid komponens sem igen volt, ami megbirkózott  tonnányi adat megjelenítésével, és mindent alád tolt ami a klasszikus desktopon alap volt.
    Mutasd a teljes hozzászólást!
  • Igen, szerintem is, egy kép átméretezésnél nyilván nem a renderelés lesz a lassú (amit a böngészõ végez) és nem a fájlok átpasszírozása a gépen belül még ha okoz is némi veszteséget a plusz javascript réteg. Viszont egy bytecode interpreter már tud lassú lenni egy JIT-hez képest, méghozzá nem kicsit, de nagyon - akár százszor lassabb is lehet. Ezért gyorsabb ma még a js: õt gépi kódra fordítja a futtató motor (már amennyire persze a dinamikus típuskezelése miatt lehet). De ha a blazor is "natív" webassemblyre fordít majd, akkor már be tudja elõzni a rendszer sebességben a javascriptet a statikus típuskezelés miatt.
    Mutasd a teljes hozzászólást!
  • Az interpreter lesz a lassú.  Így van...sokszoros a sebesség különbség a js és a blazor között.
    Viszont az AOT ezen jelentősen fog gyorsítani. Elvileg .net 5-be tervezték de végül átcsúszott a 6-osba. Reméljük addigra kész lesz és nem tolódik tovább.

    CSharpWasmBenchmark

    Én amúgy azt gondolom, hogy ha jobban felkapják (én személy szerint mindig meglepődök mennyi Blazor fejlesztő van itt a prog.hu-n is, mindig azt gondoltam csak én vacakolok vele) akkor lesznek rendes optimalizációk a browser oldalról is.
    Nem tudom valaki emlékszik-e rá, de anno 2008 körül kezdett felkapott lenni a gwt akkor csak a Chrome-ban volt értelmezhető a sebessége, mert minden más browser behalt már egy nagyobb combo boxtól is. Aztán érdekes mód mindenki összekapta magát és csináltak gyors js interpretert.
    Ilyen szempontból meg pont jó ez a hír, hogy egyre többen állnak be a wasm mögé mert talán itt is megindul az agyalás hogy lehetne gyorsabbá tenni.
    Mutasd a teljes hozzászólást!
  • Ez egy SQL szerver Wasm-ra fordítva:

    https://play.pingcap.com/
    Némi leírás:
    TiDB in the Browser: Running a Golang Database on WebAssembly
    Mutasd a teljes hozzászólást!
  • Hogy pontosan mi lassú, azt nem tudom. Az biztos, hogy ha pl. egy file inputból el akarod kérni a file-t Blazorral, akkor percekig homokórát nézel. Míg js-ből ez másodpercek kérdése.
    Az biztos, hogy a Webassembly direktben semmihez nem fér hozzá, azaz pl. File API-hoz sem.

    Konkrét kód nélkül nehéz biztosat mondani, de a fentiek alapján a legvalószínűbb tippem az lenne, hogy nem azonos dolgokat, funkcionalitást hasonlítasz össze, és amikor a Blazor-ból eléred a fájlt, azt úgy és az után teszed meg, hogy az már megjár egy lassú kapcsolaton át egy távoli szervert is, és a feltöltésre kell várnod ennyit. Vagy ki tudja mi. Mint írtam kód nélkül nehéz megmondani, de alapvetően teljesen hihetetlen, hogy _ugyanaz_ a dolog WA miatt lassabb lenne (ráadásul ennyivel) - mert miért lenne az?
    Mutasd a teljes hozzászólást!
  • Hogy pontosan mi lassú, azt nem tudom. Az biztos, hogy ha pl. egy file inputból el akarod kérni a file-t Blazorral, akkor percekig homokórát nézel. Míg js-ből ez másodpercek kérdése.
    Az biztos, hogy a Webassembly direktben semmihez nem fér hozzá, azaz pl. File API-hoz sem. Gondolom az a lassú, amig az a pár tíz kbyte képnyi adat átpasszírozódik a js interpo-on keresztül a webassemblynek.
    De ahogy írtam is, ez csak egy példa volt. Minden őrületesen lassú vele, mihelyst kilépsz a móricka-szintű rendereld bele ezt a szöveget ebbe a divbe, meg figyeld, hogy rányom valaki a submit gombra fejlesztésekből (aztán azon persze el lehet vitatkozni, hogy az Enterprise fejlesztések jó része meg is áll ezen a szinten :D ).
    A belinkelt .net 6-os roadmap alapján erről MS-nél is tudnak, hogy ezen mennyit tudnak gyorsítani, az majd kiderül. A remény hal meg utoljára. Mivel a WebAssembly az esetek jó részében zsákban próbál futni, amíg a W3C és a böngésző fejlesztők le nem szedik róla a zsákot, nem hiszem, hogy drasztikusan tudna javulni.
    Mutasd a teljes hozzászólást!
  • És ebben biztos hogy a dom manipuláció a lassú? Mert ha maga a kép átméretezés lenne az, azt megérteném, mert amennyire én tudom a blazor jelenleg nem JIT-tel, ergo van egy webassemblyben írt bytecode interpreter benne egyenesen a mono projektbõl átemelve.
    Mutasd a teljes hozzászólást!
  • Jelzem ez csak egy példa volt. Lehet, hogy épp nem átméretezni akarod a feltöltött képet, csak validálni a méreteit.
    Vagy WebRTC-t szeretnél használni, vagy sok ezer sornyi data gridet kirendereltetni, benne változásokat mutogatni, újrarendereltetni.
    Ezek mind csak példák, és nyilván nem fogok minden létező erőforrásigényesebb esetet felsorolni. De legalább kezded kapizsgálni, hogy miről beszélek :)

    A te üzleti appod, amiben van pár egyszerű oldal, ahova ki van redereltetve pár adat, meg figyelsz pár kattintást, arra simán elég lehet a WebAssembly jelen állapotában. Sőt hehehe, annak idején pont az ilyen egyszerű esetekhez készült a WebForms is a 2000-es évek elején, aztán azt is gyorsan kinőtte az élet.

    De ahogy látom, amerre vinni akarják a Blazort, ahhoz ez a jelen Webassembly állapot igencsak kevés, még ha neked most éppen meg is felel (némi extra js-ben hozzátákolással).
    Mutasd a teljes hozzászólást!
abcd