WebAssembly támogatás fog kerülni a Google V8 motorjába

WebAssembly támogatás fog kerülni a Google V8 motorjába
2016-01-12T09:19:57+01:00
2016-01-14T22:49:37+01:00
2022-10-20T17:15:37+02:00
  • Nekem szimpatikus, egy újabb lehetőség a js programok optimalizációjához. Illetve alapja lehet tetszőleges programnyelv átportolása böngésző alá, ezek után nem kell js-re konvertálni, hanem lehet direkt WebAssembly-re fordítani.
    Mutasd a teljes hozzászólást!
  • Abból, hogy a cikk szerint a többi böngészőgyártó is azonos véleményen volt (részt vettek a fejlesztésben), és nem alárúgni próbáltak (vagy legalább is nincsen róla hírek, egyenlőre).

    Ebből logikailag semmilyen módon és értelemben nem következik az, amit te írtál.

     Leszámítva a fejlesztők megadóztatását, fogalmam sincs, még miben tudhatnak azok egyetérteni.

    A digitális aláírásnak semmi köze nincs a fejlesztők megadóztatásához sem. Számos dolog van amit digitális aláírás véd, és ingyenes. És számtalan másik, amit nem véd digitális aláírás, mégis fizetni kell utána.

    Nagyon más a lehetőség, hogy megtehetsz valamit, és a trend, hogy kötelező lesz megtenned valamit.

    Mint mondtam, a logikai következtetésed eleve hibás. Ráadásul valamiféle aláírási kényszer bevezetéséhez sincs szükség a WebAssembly-re vagy bármilyen új formátumra, programozási nyelvre, stb.. Ezt - ha akarnák - a jelenlegi JavaScript fájlok esetén is megtehetnék. Persze, bármi ilyesmi teljesen értelmetlen, kivitelezhetetlen és abszurd lenne. Csak mondom.
    Mutasd a teljes hozzászólást!
  • Abból, hogy a cikk szerint a többi böngészőgyártó is azonos véleményen volt (részt vettek a fejlesztésben), és nem alárúgni próbáltak (vagy legalább is nincsen róla hírek, egyenlőre). Leszámítva a fejlesztők megadóztatását, fogalmam sincs, még miben tudhatnak azok egyetérteni.

    Nagyon más a lehetőség, hogy megtehetsz valamit, és a trend, hogy kötelező lesz megtenned valamit.
    Mutasd a teljes hozzászólást!
  • Azon gondolkodom, vajon egészen biztos-e, hogy nem a webscriptek digitális aláírhatóságának első fejlesztési lépését látjuk?

    Nem értem miből jutottál erre a következtetésre. JavaScript fájlokat, sőt, akármilyen bájtsort el lehet látni digitális aláírással.
    Mutasd a teljes hozzászólást!
  • Nem hát! Egy belso loop csak 50..100 soros szokott lenni. Es meglepodnel, hogy mennyire egyszeru a debug: mivel nincs if, emiatt nem divergens a kod es a mukodes ellenorzesehez eleg 1x lefuttatni es a reszeredmenyeket osszehasonlitani a testcase-vel.
    A hiba eszlelese is sokkal egyszerubb: mikozben te nem tudsz teljes teszt lefedettseget csinalni a 100000 sorodnak, addig az en 50..100 soros kodom mindegyik sora lefut 100000szer. Ez az az 50..100 sornyi kod, ami az ido 99%-aban fut, eleg nehez igy egy hibanak elbujnia, hogy allandoan szem elott van. Ezeknek az optimizalt reszeknek megvan az az elonyos mellekhatasa, hogy ha raszall egy légy, az egész elromlik.
    Mutasd a teljes hozzászólást!
  • Azon gondolkodom, vajon egészen biztos-e, hogy nem a webscriptek digitális aláírhatóságának első fejlesztési lépését látjuk?
    Mutasd a teljes hozzászólást!
  • Valamit nem csak megírni kell, de fenn is kell tartani, és minél komplexebb valami, szorgos kezű hackerek annál előbb találnak rajta biztonsági lyukat.

    Tehát ezért jobb ha eleve meg sem kell írni, és ha a kódbázis sokkal kisebb. Ezt mondtam. Ez nem érted.

    És mivel a js motorok elég sok procin futnak, gondolom hogy a legtöbb js motor belül csinál előbb egy köztes kódot (hasonlóan a gcc-hez) és ezt fordítja végrehajtható kóddá, nem pedig külön fordítója van az x86, arm, stb. prociknak.

    Ezt egyrészt motorja válogatja. Konkrétan a V8 például közvetlenül generál gépi kódot. Másrészt ennek semmi köze nincs a fentiekhez. Illetve a fent írtak attól függetlenül igazak, hogy a motor milyen módon futtatja a kódokat.

    Én ezt próbáltam volna standardizálni, lehetőleg minél szűkebb utasításkészlettel, és ezt próbáltam volna minél biztonságosabbá tenni.

    Ennek adott esetben semmi értelme nem lett vona. Egyrészt azért, mert a cél nem a biztonságosabbá tétel volt, hanem a kódébetöltés, - értelmezés és -futtatás felgyorsítása. Ezekkel pedig szembemegy egy túl egyszerű utasításkészlet.

    Másrészt azzal, hogy kidolgozol egy új VM-et, egy új futtatómotort, azzal első körben nem növeled a biztonságot, hanem csökkented. Mert egy új kódbázisban nyilvánvalóan több lesz a hiba, mint egy olyanban, amiben már évek óta keresik azokat. Szóval ez azért se lett volna praktikus lépés.

    A JS-motoroknak egyébként is a biztonság a legkevésbé problémás pontjuk, és ezen a téren nagyjából sokkal jobban állnak, mint akármelyik konkurens VM. A WebAssembly sem ezt - a szinte nem is létező - problémát próbálja orvosolni, hanem azokat, amiken tényleg van mit javítani: az indulási és futási sebességet.
    Mutasd a teljes hozzászólást!
  • Ez tök jó, de szerintem te sem szeretnél egy 100 000 soros ilyen kódban hibát keresni.
    Mutasd a teljes hozzászólást!
  • Valamit nem csak megírni kell, de fenn is kell tartani, és minél komplexebb valami, szorgos kezű hackerek annál előbb találnak rajta biztonsági lyukat.
    És mivel a js motorok elég sok procin futnak, gondolom hogy a legtöbb js motor belül csinál előbb egy köztes kódot (hasonlóan a gcc-hez) és ezt fordítja végrehajtható kóddá, nem pedig külön fordítója van az x86, arm, stb. prociknak. Én ezt próbáltam volna standardizálni, lehetőleg minél szűkebb utasításkészlettel, és ezt próbáltam volna minél biztonságosabbá tenni.
    Mutasd a teljes hozzászólást!
  • Egy egyszerűbb bytekód értelmezőt nem lett volna sokkal könnyebb biztonságossá tenni,

    Annál semmi sem könnyebb, mint amikor nem kell valamit megírni. Illetve semmi sem tesz jobban biztonságosabbá egy kódbázist, mint ha csak fele akkora, mint egyébként lenne (mert mondjuk egy közös VM-et használ két külön helyett).

    és e fölé írni egy javascript interpretert ami ezt röptében fordítja le erre a már biztonságos bytekódra

    Nem, mert ettől a JavaScript kódok futása lassult volna, ami nyilván tökéletesen ellentétes a kívánalmakkal. És mert ha az új bájtkód szemantikája nem illeszkedik tökéletesen a JavaScript-éhez, akkor a régebbi - a WebAssembly-t nem ismerő - böngészőkön csak iszonyatos emulációs overhead árán vagy még a mellett sem tudott volna csak működni.

    mint egy ilyen, első hangzásra elég komplexnek tűnő dolgot biztonságosan tartani ?

    Ez pont hogy nem komplex és nem kevésbé biztonságos, hanem a lehető legegyszerűbb és legbiztonságosabb módja a böngészős környezet átalakításának olyan módon, hogy az korábbiaknál optimálisabb kódbetöltést és -generálást tegyen lehetővé, miközben tökéletesen őrzi a visszafelé kompatibilitást is.
    Mutasd a teljes hozzászólást!
  • Egy egyszerűbb bytekód értelmezőt nem lett volna sokkal könnyebb biztonságossá tenni, és e fölé írni egy javascript interpretert ami ezt röptében fordítja le erre a már biztonságos bytekódra, mint egy ilyen, első hangzásra elég komplexnek tűnő dolgot biztonságosan tartani ?
    Mutasd a teljes hozzászólást!
  • A CLR és JVM egy köztes, illetve közvetítő jellegű virtuális gépet definiálnak, ami önmagában nem tükrözi sem a forrásoldal, sem a tényleges futtatást végző hardver szemantikáját. A műveleti kódjaik ezen kívül rendkívül egyszerűek, gyakorlatilag regisztereket és/vagy memóriacellákat írnak és olvasnak, és az egyetlen magasszintű műveleteket az objektummanipulációval kapcsolatosak (pl. példányosítás, metódushívás) képezik.

    Ezzel szemben a WebAssembly utasításkészlete szemantikájában a JavaScript-et tükrözi, és ezzel összefüggésben ismer olyan magasszintű fogalmakat is, mint pl. a lokális változók vagy az utasításblokkok (az eljáráson belül is). Van benne bájtszinten címezhető virtuális memóriatér, de nincs feltétlenül minden változó erre leképezve valamilyen ismert és rögzített ábrázolási módon. Ami még ennél is fontosabb: a WebAssembly megőrzi (illetve megőrizheti) a forrásnyelv teljes szemantikai struktúráját, és nem alakítja egy lineáris, primitívekből álló műveletsorrá azt.

    Pl. C#-ban és Java-ban ha egy if()-ben egy összetett kifejezés szerepel, akkor az a CLR/JVM bájtkódban úgy fog megjelenni, hogy szép sorban egymás után először jönnek a kifejezést kiértékelő, kiszámító elemi utasítások (amik regisztereket/memóriacellákat olvasnak, írnak és esetleg metódushívásokat végeznek), és utána jön a szintén elemi feltételvizsgálat. Aminek ezen a ponton már gőze sincs arról, hogy az eredmény hogyan és miből származott. A vizsgált eredményt az if() előtt és az if()-ben kiértékelő forrásból is ugyanaz a lineáris kód fog fordulni.

    Ezzel szemben WebAssembly-ben az if() gyakorlatilag "beburkolja" a kifejezést (ahogy a Java vagy C# forrásban is teszi), és így pontosan lehet tudni, hogy a teljes műveleti halmazból mely utasítások tartalmaznak a vizsgált kifejezés számításához, és mik teljesen függetlenek attól. A kódgenerátor pedig átugorhatja az egész, a feltételes elágazást befolyásoló kifejezésblokkot (és csak azt), ha arra éppen ott és akkor nincs szüksége.

    A WebAssembly csak abban az értelemben bájtkód, hogy nem igazán arra van tervezve, hogy ember olvassa vagy írja (ebből a szempontból hasonló az asm.js-hez), reprezentációra pedig nem nyersszöveges, hanem egy kompakt bináris kódolást használt. Valójában azonban csak egy alternatív nyelv a JavaScript VM felett, ami sokkal szigorúbb szabályokkal, illetve az optimális tárgykód generálását megkönnyítő sajátosságokkal (pl. rögzített típusok, explicit típusátalakítások) rendelkezik.

    Ez utóbbi sajátosságok előnye, hogy támogatásához nem kell egy teljesen új szemantikára épülő VM-et rakni a böngészőbe, aminek kifejlesztése, karbantartása rengeteg időt emészt fel, új támadási felületeket nyit, és ami csak problémásan tud együttműködni a már eleve ott lévő JavaScript VM-mel, illetve az utóbbin futó JavaScript kódokkal. Ehelyett a WebAssembly és a JavaScript kódok tökéletesen együtt tudnak működni egymással, a wasm kódok futtatásához pedig csak egy nagyon vékony réteget kell a JavaScript VM felé írni, ami szinte csak a JavaScript kódok értelmezését cseréli le a wasm kódokéra. Amik így ráadásul pontosan ugyanazon biztonsági korlátok és szabályrendszer mellett futnak, mint a JS kódok is.
    Mutasd a teljes hozzászólást!
  • A bájtkód nem a forrást kódolja (Javában biztosan nem, de szerintem .NET alatt sem), hanem egy annál alacsonyabb szintű reprezentáció, amit akár már közvetlenül is lehet futtatni (általában interpreterrel, de egy időben próbálkoztak Java bájtkódot közvetlenül futtató processzorral is). Az más kérdés, hogy a fordítók nem szoktak olyan brutális átrendezéseket meg optimalizációkat csinálni egy bájtkódon, mint mondjuk egy x86-os tárgykódon, ezért relatíve könnyű decompilert írni rá, ami az eredeti forrás lényegét vissza tudja adni.
    Mutasd a teljes hozzászólást!
  • Javát még sosem decompile-oltam, de C#-ot párszor már igen, és azt találtam, hogy gyakorlatilag csak a kommentek és a privát változók egy részének az egyedi elnevezése "veszett el" a compile-decompile alatt. Eddig azt gondoltam a Java is ilyen, ezek szerint tévedtem? És itt több nyerhető vissza a forrásból, vagy miben áll a különbség? Mármint ha a forrás visszanyerhető bytekódból, akkor a bytekód a forrást kódolja, nem?

    Disclaimer: Nem kívánok kötözködni, veszekedni, újabb parttalan iterációjába fogni a dinamikus/statikus/compiled/interpreted/kutyafüle nyelvekkel kapcsolatban, csak kíváncsi vagyok.
    Mutasd a teljes hozzászólást!
  • Újra feltalálták a Javát?

    Nem. Főleg nem, hogy a WebAssembly nem a klasszikus értelemben vett bájtkód, mert nem a forrásból generált lineáris műveleti kódhalmazt, hanem magát a forrást (is) kódolja. Mármint annak az AST fáját.

    Inkább valami olyasmi, mint amilyen PHP alatt az opkód-cache, vagy ahogyan a nagyon régi, mikroszámítógépes időkben a BASIC értelmezők a memóriában tárolták a programkat. Bár igazából mindegyik hasonlat sántít.

    Mondjuk a név maga ebből a szempontból teljes misnomer, mert köze nincs az assembly-hez, sőt, annak kb. szöges ellentettjét képezi minden szempontból.
    Mutasd a teljes hozzászólást!
  • Sting csak annyit mond, hogy aki nem tudja, hogy egy program futási sebességét nem a forráskód nyelve határozza meg amiben írták, az szakmailag annyira el van veszve, hogy nem is érdemes szót csépelni rá.
    Mutasd a teljes hozzászólást!
  • A nagy teljesitmenyu dolgoknal nem szamit, hogy bármin leforduljon. Eleg, ha egyvalamin lefordul, de azon a leheto legjobban fut (Win, Mac, Linux, azt' le vannak fedve a 100GFlops/s teljesitmenyu desktop platformok ugyanazzal az asm-al). Ott egy koztes layer (ami a mobil vilagban nagyon kenyelmes) csak feleslegesen lassitana: fel van keszulve mindenre, de mindig ugyanazt kell csinalnia.

    Hardverfuggetlenseg x86-on belul: A 2013-as MSVC-nek ha jol tudom SSE3-as processzor a minimum. Te egy SSE2-es-rol beszelsz.

    A gcc-t meg 2evente itt kiprobalgatjuk :D A tapasztalatok alapján az gyerekcipoben jar még. Csak olyan kodot tud vektorizalni, amik egyszeruen vektorizalhatoak. Ilyenek pedig a peldak. A valos feladatoknal pedig nem mindig 32/64 bites adattal kell dolgozni (16/8 is lehet es azok meghatekonyabbak ugy). Az sem jarhato ut, hogy a bonyolultabb feladatot tobb pelda-megoldas segitsegevel ollozzuk ossze, mert az adatok akkor nem a regiszterek kozott fognak aramlani. Vannak olyan helyzetek, amikor van egy szekvencialis resz is a javareszt parhuzamos dolgok kozott: ahhoz mar gondolkodni kell erosen, hogy megoldhato legyen shuffling-al(rengeteg lehetoseg van rá) meg specialis nem-SIMD utasitasokkal, mint pl a horizontalis osszeadassal, csak azert, hogy nehogy vissza kelljen menni az hagyomanyos x86 világba, amely atmenet nagy idoveszteseggel jar a feladathoz kepest.

    Pont a kompex dolgokkal van baj. Arrayokon vegzett muveleteket remekul megold a gcc viszont az olyan helyzeteknel, ahol nincsenek array-ok, hogy egy xmm-reget egy lepesben be tudjon tolteni, hanem kell valami komplex shuffling is amiatt, hogy a kesobbi feldolgozas viszont joval gyorsabb legyen, ott meg van love. Azt meg nem csinalhatod, hogy eloszor egy kulon pass-al atvarialod az adatokat es aztan engeded ra a gcc-t, mert akkor mar nem a regisztereken belul dolgozol.

    Na de ne csak szajtepes legyen, hanem konkret pelda is: Legutobb ezzel az egyszeru feladattal talalkoztam:

    void f(float *in, float *out) { out[0] = in[0]; out[1] = in[0]+in[1]; out[2] = in[0]+in[1]+in[2]; out[3] = in[0]+in[1]+in[2]+in[3]; }
    Ebbol az MSVC azt csinalja, hogy:

    movss xmm0,dword ptr [$010e6124] movss xmm1,dword ptr [$010e6128] addss xmm1,xmm0 movss dword ptr [$010e9988],xmm0 movss dword ptr [$010e998c],xmm1 addss xmm1,dword ptr [$010e612c] movss dword ptr [$010e9990],xmm1 addss xmm1,dword ptr [$010e6130] movss dword ptr [$010e9994],xmm1 //egyenkent csinal minden muveletet

    En meg azt, hogy:

    movups xmm0,[eax] pand xmm0,[edx].and1110 pshufd xmm2,xmm0,76 haddps xmm0,[eax] haddps xmm2,xmm0 movups [edx], xmm2
    Nalam is 4 aritmetikai utasitas van, viszont azok eloszthatoak tobb muveletvegzo kozott is (hadd megy az ADDER-be, a pand meg a pshufd meg 2 masikba is mehet.
    Az en oldalamon pedig az elso es az utolso MOV a gyakorlatban kihagyhato, mert a konkret feladatnal eleve sse regiszterekben dolgozunk. Nem elhanyagolhato elony még, hogy a manualis asm-ba siman bele lehet fonni a programnak egy masik reszet is, ezaltal megjobb kihasznaltsagot elerni a muveletvegzokben. A gcc meg ezt nem engedi meg nekem ott csak remenykedhetek, hogy van annyi esze :D

    Az MSVC javára irando, hogy ugyesen eszrevette a sorozatot es csak 3 osszeadassal oldotta meg. Viszont ezaltal csinalt egy dependency chaint az add-bol, aminek viszonylag nagy a latency-je.

    En egy ideje csinalgatok egy tool-t amiben atlathatobba lehet tenni ezeket a nyakatekert utasitasokat. A klasszikus SIMD-hez eleg lenne egy C-szeru nyelv is, de az SSE már rég nem klasszikus SIMD. (Es pont ez tortenik a GPU-knal is: ott 64 SIMD volt, de most mar lehetoseg van a szomszedos 'thread'-ekbol is bemenetet szerezni extra orajel nelkul.)

    Csatolva, hogy hogy nez ,ki a fenti horizontalis osszeadasos dolog. Es van még jó pár ilyen bonyolultabb lego kocka, mint a HADD, amelyekkel jo lenne, ha a compilerek tudnanak gondolkodni. Vegul pedig az adatstrukturak attervezesere is meg kell tanitani a GCC-t, hogy kepes legyen tavolrol szemlelni az egesz feladatot. Csak aztán mehetek végre nyugdíjba :D
    Mutasd a teljes hozzászólást!
    Csatolt állomány
  • Amennyire én tudom, a ChromeOS már most is tud droidos appokat futtatni. Ugyanazzal az API-val kicsit más design mellett már meg is van a desktop is. Ez inkább a web fejlesztésének adhat úgy lendületet: előre vetíti egy egységes webes platofrm létezését amit programozhatsz javascriptben, dart-ban, C#-ban, Javában, C++-ban, pythonban, PHP-ben, amiben csak akarsz mind kliens mind szerver oldalon.
    Ezt elvben megtehetted persze js-re fordítva is, de ez azért egy nagyságrenddel elegánsabb és valószínűleg gyorsabb is.
    Mutasd a teljes hozzászólást!
  • Csak arra próbáltam rávilágítani, hogy bytecode engine-ek már léteznek, sz'al nincs itt szó semmi radikális újításról.
    Mutasd a teljes hozzászólást!
  • Inkább arra gondolnék, hogy ha már van egy chrome nevű platformja a googlenak, - ami már szinte mindent tud, - akkor szeretne egy kicsit turbózni a sebességen, hogy ne preferálhassák a desktop alkalmazást a betöltési sebesség miatt.
    Ez kérem a chromeOS előkészítése és nem pedig a fejlesztők életének az egyszerűsítése.
    Nem fognak silverlightot meg javat használni.
    Cél a desktop.
    Mutasd a teljes hozzászólást!
  • Es a mai assembly-rol meg alig esik szó, holott bizonyos feladatokat 2..20x gyorsabban meg lehet benne..

    Még egy újabb nullát is simán utána tehetnél, de tudod itt az asm-ről tilos beszélni, mert jön Sting, és aki olyat mer írni, hogy a javascript nem gyorsabb még a fénysebességnél is, az kap egy bant
    Mutasd a teljes hozzászólást!
  • Azért egy gcc-hez képest nem biztos hogy annyival jobb kódot tudsz csinálni asm-ben, legalábbis ha komplex dologról van szó sok változóval, esetleg függvényekkel.

    A bytekódnak pedig megvan az az elvi előnye, hogy procifüggetlen. Azaz lehet(ne) olyan fordítót írni ami a bytekódodból jobb gépi kódot csinál az adott procira mint a gcc, Pl. egy P7-nek lehetnek olyan utasításai amit a korábbi procik nem tudnak, így egy általános i586-ra fordított kódban nem szerepelhetnek.
    Mutasd a teljes hozzászólást!
  • Ja :D Lenyulják az assembly nevet. Gondolom mert a nosztalgia miatt sokan felkapjak a fejuket.

    Es a mai assembly-rol meg alig esik szó, holott bizonyos feladatokat 2..20x gyorsabban meg lehet benne oldani, mint abban az asm-ban, amit a legtobb ember itt ismer es aminek a hasznalata manapsag mar felesleges, mert a compilerek is ugyanolyan jol (ha nem jobban) ismerik, mint az emberek.

    A modern (2000 utani, haha) asm is egy lehetoseg a hatekonysag novelesere, mint az, hogy ha megirjuk a programot tobbszalura. Mindketto kell ahhoz, hogy optimalis legyen a proszesszor kihasznaltsaga, csak az utobbi nehezebb, mint a paralell for().

    Ja es mar nem TurboAssembler szintu dolgok vannak. Van már if/loop/struct tamogatas hogy ne legyen az egesz spagetti jellegu.

    Na de jobb, ha most visszaadom a szót a  JavaScript-nek. :D
    Mutasd a teljes hozzászólást!
  • Ez - szerintem - speciel bocsánatos bűn...

    ...a "W2000 hack"-en kívül szó szerint évek (évtizedek) óta nem kellett desktop assembly-t írnom, de még mindig eszembe villan néha az x86 (Turbo)assembler. :) Persze lehet hogy az új generáció már másként van ezzel.

    Múltkor belefutottam egy ilyenbe, mikor az egyik C#-os kóder cimborámmal beszélgettünk egy sör fölött és megemlítettem, hogy "milyen jó, hogy nem assemblyben kell megcsinálni" egy feladatot, mire kiderült hogy neki az alapértelmezésben a System.Assembly osztályt jelenti. :D
    Mutasd a teljes hozzászólást!
  • A cikk képe alapján pedig az x86 asm-ot talaltak fel ujra. 
    Mutasd a teljes hozzászólást!
  • Újra feltalálták a Javát?



    (Ok, a nyílt szabványú javát, de akkor is...)
    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