Jau du dešimtmečius žiniatinklio naršyklėje galime naudoti tik vieną programavimo kalbą: „JavaScript“. Lėta trečiųjų šalių dvejetainių papildinių mirtis atmetė kitas kalbas, tokias kaip „Java“ ir „Flash“ „ActionScript“, kaip pirmos klasės piliečius kuriant internetą. Kitos žiniatinklio kalbos, pvz., „CoffeeScript“, yra tik sukompiliuotos į „JavaScript“.
Bet dabar mes turime naują galimybę: „WebAssembly“ arba trumpai - „WASM“. „WebAssembly“ yra nedidelis, greitas dvejetainis formatas, žadantis beveik savitą žiniatinklio programų našumą. Be to, „WebAssembly“ sukurtas kaip bet kurios kalbos kompiliavimo tikslas, o „JavaScript“ yra tik viena iš jų. Dabar, kai kiekviena pagrindinė naršyklė palaiko „WebAssembly“, laikas pradėti rimtai galvoti apie tai, kaip rašyti kliento programas žiniatinkliui, kurias galima sudaryti kaip „WebAssembly“.
Verta paminėti, kad „WebAssembly“ programos nėra skirtos pakeisti „JavaScript“ programos - bent jau dar ne. Verčiau galvokite apie „WebAssembly“ kaip apie kompanionas į „JavaScript“. Kai „JavaScript“ yra lankstus, dinamiškai įvestas ir pateikiamas per žmonėms įskaitomą šaltinio kodą, „WebAssemble“ yra greitas, tvirtai surinktas ir pateikiamas kompaktišku dvejetainiu formatu.
Kūrėjai turėtų apsvarstyti „WebAssemble“, jei reikia daug darbo, pavyzdžiui, žaidimų, muzikos srautinio perdavimo, vaizdo įrašų redagavimo ir CAD programų.
Kaip veikia „WebAssembly“
W3C sukurtas „WebAssembly“, jo kūrėjų žodžiais, yra „kompiliavimo tikslas“. Kūrėjai nerašo „WebAssembly“ tiesiogiai; jie rašo pasirinkta kalba, kuri tada sukomponuojama į „WebAssembly“ baitų kodą. Tada baitų kodas paleidžiamas kliente, paprastai žiniatinklio naršyklėje, kur jis išverčiamas į gimtąjį mašinos kodą ir vykdomas dideliu greičiu.
„WebAssembly“ kodas skirtas greičiau įkelti, išanalizuoti ir vykdyti nei „JavaScript“. Kai žiniatinklio naršyklė naudoja „WebAssemble“, vis tiek reikia atsisiųsti WASM modulį ir jį nustatyti, tačiau visi kiti dalykai, lygūs „WebAssembly“, veikia greičiau. „WebAssembly“ taip pat pateikia „sandboxed“ vykdymo modelį, pagrįstą tais pačiais saugos modeliais, kurie dabar yra „JavaScript“.
Šiuo metu „WebAssembly“ paleidimas žiniatinklio naršyklėse yra labiausiai paplitęs naudojimo atvejis, tačiau „WebAssembly“ yra daugiau nei internetinis sprendimas. Galų gale, kai „WebAssembly spec“ formuojasi ir jame atsiranda daugiau funkcijų, jis gali tapti naudingas programose mobiliesiems, darbalaukio programose, serveriuose ir kitose vykdymo aplinkose.
„WebAssembly“ naudojimo atvejai
Pagrindinis „WebAssembly“ naudojimo atvejis yra tikslas rašyti naršyklės programinę įrangą. Komponentus, kurie yra kompiliuojami „WebAssembly“, galima rašyti bet kuria iš daugelio kalbų; tada galutinė „WebAssembly“ naudingoji apkrova klientui pateikiama per „JavaScript“.
„WebAssembly“ buvo sukurtas atsižvelgiant į daugybę efektyvumo reikalaujančių, naršyklėmis pagrįstų naudojimo atvejų: žaidimų, muzikos srautinio perdavimo, vaizdo įrašų redagavimo, CAD, šifravimo ir atpažinimo.
Apskritai, nustatant konkretų „WebAssembly“ naudojimo atvejį, pamokoma sutelkti dėmesį į šias tris sritis:
- Didelio našumo kodas, kuris jau egzistuoja tiksline kalba. Pvz., Jei turite didelės spartos matematikos funkciją, jau parašytą C, ir norite ją įtraukti į žiniatinklio programą, galite ją įdiegti kaip „WebAssembly“ modulį. Mažiau našumo kritinės, vartotojui skirtos programos dalys gali likti „JavaScript“.
- Didelio našumo kodas, kurį reikia parašyti nuo nulio, kur „JavaScript“ nėra idealus. Anksčiau tokiam kodui parašyti galėjo būti naudojamas asm.js. Vis tiek galite tai padaryti, tačiau „WebAssembly“ laikomas geresniu ilgalaikiu sprendimu.
- Darbalaukio programos perkėlimas į žiniatinklio aplinką. Daugelis „asm.js“ ir „WebAssembly“ technologijų demonstracinių versijų patenka į šią kategoriją. „WebAssembly“ gali suteikti pagrindą programoms, kurios yra ambicingesnės, nei tik GUI, pateikiama per HTML. (Žr. „WebDSP“, „Zen Garden“ ir „Tanks“ demonstracines versijas.) Tačiau tai nėra nereikšmingas pratimas, nes visus būdus, kuriuos darbalaukio programa sieja su vartotoju, reikia susieti su „WebAssembly“ / HTML / „JavaScript“ atitikmenimis.
Jei turite esamą „JavaScript“ programą, kuri nestumia jokių našumo vokų, geriausia palikti ramybėje šiame „WebAssembly“ kūrimo etape. Bet jei jums reikia, kad programa veiktų greičiau, gali padėti „WebAssembly“.
„WebAssembly“ kalbos palaikymas
„WebAssembly“ nėra skirtas rašyti tiesiogiai. Kaip rodo pavadinimas, tai labiau panašu į surinkimo kalbą, kurią mašina turi vartoti, nei aukšto lygio, žmonėms pritaikytą programavimo kalbą. „WebAssembly“ yra arčiau tarpinio vaizdavimo (IR), kurį sukuria LLVM kalbos kompiliatoriaus infrastruktūra, nei jis yra kaip „C“ arba „Java“.
Taigi dauguma darbo su „WebAssembly“ scenarijų apima kodo rašymą aukšto lygio kalba ir jo pavertimą „WebAssembly“. Tai galima padaryti bet kuriuo iš trijų pagrindinių būdų:
- Tiesioginis kompiliavimas. Šaltinis išverčiamas į „WebAssembly“ naudojant pačios kalbos kompiliatoriaus įrankių grandinę. „Rust“, „C / C ++“, „Kotlin / Native“ ir D dabar turi įprastus būdus, kaip skleisti WASM iš kompiliatorių, palaikančių tas kalbas.
- Trečiųjų šalių įrankiai. Kalbos įrankių grandinėje nėra vietinio WASM palaikymo, tačiau norint konvertuoti į WASM galima naudoti trečiosios dalies įrankį. „Java“, „Lua“ ir .Net kalbų šeima turi šiokį tokį palaikymą.
- „WebAss Assembly“ vertėjas. Čia pati kalba nėra išversta į „WebAssembly“; veikiau kalbos vertėjas, parašytas „WebAssemble“, vykdo šia kalba parašytą kodą. Tai yra pats sudėtingiausias būdas, nes vertėjui gali būti keli megabaitai kodo, tačiau jis leidžia egzistuojančiam kalbai parašytam kodui paleisti visus, išskyrus nepakitusius. Python ir Ruby abu verčia vertėjus į WASM.
„WebAssembly“ funkcijos
„WebAssembly“ dar tik ankstyvoje stadijoje. „WebAssembly“ įrankių grandinė ir diegimas išlieka artimesni koncepcijos įrodymui nei gamybos technologijai. Tai reiškia, kad „WebAssembly“ saugotojai yra pasiryžę padaryti „WebAssembly“ naudingesnį įgyvendindami keletą iniciatyvų:
Šiukšlių surinkimo primityvai
„WebAssembly“ tiesiogiai nepalaiko kalbų, naudojančių šiukšlių surinktus atminties modelius. Kalbos, tokios kaip „Lua“ ar „Python“, gali būti palaikomos tik ribojant funkcijų rinkinius arba įterpiant visą vykdymo laiką kaip „WebAssembly“ vykdomąjį failą. Tačiau vyksta darbas, palaikantis šiukšlių surinktus atminties modelius, neatsižvelgiant į kalbą ar įgyvendinimą.
Siūlai
Gimtoji siūlų palaikymas yra būdingas tokioms kalboms kaip „Rust“ ir „C ++“. Jei nėra „WebAssembly“ siūlų palaikymo, tai reiškia, kad ištisos „WebAssembly“ programinės įrangos klasės negali būti parašytos šiomis kalbomis. Pasiūlyme pridėti „Threading“ prie „WebAssembly“ kaip vieną iš įkvėpėjų naudojamas „C ++“ gijų modelis.
Masinės atminties operacijos ir SIMD
Masinės atminties operacijos ir SIMD (viena instrukcija, keli duomenys) lygiagretumas yra privalumas programoms, kurios šlifuoja duomenų krūvas ir kurioms reikalingas įprastas procesoriaus pagreitis, kad neužspringtų, pvz., Mašininio mokymosi ar mokslinių programų. Pateikiami pasiūlymai įtraukti šias galimybes į „WebAssembly“ per naujus operatorius.
Aukšto lygio kalbos konstrukcijos
Daugelis kitų „WebAssembly“ svarstomų funkcijų tiesiogiai nukreipia į aukšto lygio konstrukcijas kitomis kalbomis.
- Išimtys gali būti imituojamas „WebAssembly“, bet negali būti įgyvendinamas savaime per „WebAssembly“ instrukcijų rinkinį. Siūlomas išimčių planas apima išimčių primityvus, suderinamus su C ++ išimčių modeliu, kuriuos savo ruožtu galėtų naudoti kitos „WebAssembly“ sudarytos kalbos.
- Nuorodų tipai palengvinkite aplink objektus, naudojamus kaip nuorodas į pagrindinę aplinką. Tai palengvintų šiukšlių surinkimą ir daugybę kitų aukšto lygio funkcijų, kurias būtų lengviau įgyvendinti „WebAssembly“.
- Uodegos skambučiai, dizaino modelis, naudojamas daugeliu kalbų.
- Funkcijos, kurios grąžina kelias reikšmes, pvz., per „Python“ arba „C #“ rinkinius.
- Ženklų pratęsimo operatoriai, naudinga žemo lygio matematikos operacija. (LLVM taip pat palaiko juos.)
Derinimo ir profiliavimo įrankiai
Viena didžiausių perkelto „JavaScript“ problemų buvo derinimo ir profiliavimo sunkumai dėl nesugebėjimo koreliuoti tarp perkelto kodo ir šaltinio. Su „WebAssembly“ turime panašią problemą ir ji sprendžiama panašiai (šaltinio žemėlapio palaikymas). Žr. Projekto pastabą apie planuojamą įrankių palaikymą.
