Már WebAssembly-ben is lehet programozni a Linux-okra

Már WebAssembly-ben is lehet programozni a Linux-okra
2018-09-27T13:46:02+02:00
2018-10-21T00:33:08+02:00
2022-10-18T14:45:38+02:00
  • ogy online futási statisztikákat is tud majd készíteni, és akár egy kódrész következő futtatására kicseréli azt, vagy a következő programindítás/kódtöltés folyamán már másra optimalizálja a kódot a statisztika alapján.

    Java-ban ez már nagyon régen így van... szerintem legalább Java 5 óta, lehet hogy régebben is volt már. Nem kell hozzá újraindítás, már a következő metódus futtatáskor ki tudja cserélni.

    Újabban pedig ha jól rémlik, már ki is tudja írni fileba, hogy következő futtatáskor vissza tudja tölteni.

    Mondjuk az új verzióknál (debug közben) már valóban briliánsan megy, hogy belejavítok egy kódba és pl. a ciklus következő lefutásakor már az új feltételt vagy ciklustörzset debuggolom. Itt határozottan megvan a JIT előnye.

    Na az viszont nem a JIT miatt van, hanem a dinamikus osztálybetöltés és -eldobás miatt. A JIT majd később jön elő, mikor már az újonnan betöltött kódról is van elég statisztika.
    Mutasd a teljes hozzászólást!
  • Ja, és volt még szó (a JIT előnyeiként) arról, hogy az assembly betöltésekor (JIT fordítás) valami jogosultságokat is figyel és nem indul el az a kód, amit olyan jogú user indít, akinek arra nincs jogosultsága... vagy valami ilyesmi (de régen volt, meg angolul, ami nálam alacsonyabb megértési és megjegyzési hatékonyságú, lassabban és többször kell olvasni hozzá, így homályosabb egy egyszerű olvasás után).

    De lehet hogy ezeket a ficsöröket dobták, mint kevésbé hasznosakat és az időt pl a Roslyn-ba fektették :)
    Mutasd a teljes hozzászólást!
  • Pont ezért létezik a gépi kód csak futás időben

    Nem tudom a jelenlegi JIT fordító már tud-e ilyet, de az elején, tervbe vették (magyarázatként, miért jobb a JIT, mint a platform fordítás), hogy online futási statisztikákat is tud majd készíteni, és akár egy kódrész következő futtatására kicseréli azt, vagy a következő programindítás/kódtöltés folyamán már másra optimalizálja a kódot a statisztika alapján.

    Mondjuk ez az elv az SQL szervereknél bejött, nem tudom valós értelme van-e programoknál.

    Mondjuk az új verzióknál (debug közben) már valóban briliánsan megy, hogy belejavítok egy kódba és pl. a ciklus következő lefutásakor már az új feltételt vagy ciklustörzset debuggolom. Itt határozottan megvan a JIT előnye.
    Mutasd a teljes hozzászólást!
  • Pont ezért létezik a gépi kód csak futás időben, mert erre másnak sem igazán van szüksége...

    Na jó, amúgy az ok valószínűleg az, hogy a C# fordító finoman szólva sem tökig optimalizált gépi kódot csinál a bytekódból, viszont azt elég gyorsan ahhoz, hogy sok értelme ne legyen cachelni.

    Ha viszont valaki venné a fáradtságot, és csinálna egy igazán optimalizált bytekód->gépi kód fordítót, ami valóban optimális, az adott processzor utasításkészletére szabott gépi kódot csinál és vagy fél óráig fordít egy nagyobb appot, akkor már lenne értelme ennek.

    De az igazság az, hogy ha megnézel egy .NET-es proginak a disassembly window-ját debuggolás közben úgy, hogy az optimalizálás be van kapcsolva, akkor azt látod, hogy annyira nem is rossz az a gépi kód ami a C#-ból fordul...
    Mutasd a teljes hozzászólást!
  • Ez a gondolatmenet nem túl objektív.
    Mutasd a teljes hozzászólást!
  • Ismerem, de még soha nem volt rá szükségem.
    Mutasd a teljes hozzászólást!
  • és egy telepító program ezt az állományt húzná le és telepítés közben fordítaná [*] az adott harverre, ahol a bináris futtatható kód települne.

    Én mostanában C#-al nyomom, ott tulajdonképpen ez történik röptében, csak ugye a bytekód tárolódik permanensen míg a gépikód az ami csak futásidőben létezik.

    Ngen.exe (Native Image Generator) ?
    Mutasd a teljes hozzászólást!
  • Szerintem is nagy dobás lenne, ha azokat a változótípus/memória információs táblázatokat, meg szintaxis fákat, miegymásokat, amiker a GNU C++ köztes kódként fordít sikerülne szerializálnia és egy telepító program ezt az állományt húzná le és telepítés közben fordítaná [*] az adott harverre, ahol a bináris futtatható kód települne.

    Én mostanában C#-al nyomom, ott tulajdonképpen ez történik röptében, csak ugye a bytekód tárolódik permanensen míg a gépikód az ami csak futásidőben létezik.

    A GNU megléphetné, hogy nála a bytekód az ideiglenes és az adott gépre optimalizált gépikód tárolódik permanensen.

    Sőt, mivel ugye a végső fordítás+linkelés a letöltö-telepítő-betöltő modul dolga, akár még multiplatform alkalmazás terjesztése is megoldható ezzel a trükkel.

    [*] esetleg a felhőben fordulna a telepítótól kapott célgép infói alapján és úgy töltődne a tárgykód. Végülis a felhőben a sok egyforma hw+sw miatt nagy munka megtakarítás várható (cache lehetőség).
    Mutasd a teljes hozzászólást!
  • Az ideális megoldás az az, ha a köztes kódot a setup során fordítja a rendszer gépi kódra. A statikus bináris azért nem az, mert van egy rakás proci, ugyanakkor ma általában kijön egy 32 bites és egy 64 bites verzió az ARM-ra és az x86-ra ami finoman szólva nem annyira optimális. Viszont Jucika néni nem fogja 3 órán keresztül fordítani az Office-t a laptopján még akkor sem, ha ott a forráskód.
    Mutasd a teljes hozzászólást!
  • Nem, az a fordítási procedura része. A forrást "előfordítja" egy tárgy (CPU) kódra alakításhoz alkalmasabb adathalmazra.

    De itt is egy (több lépcsős-összetett)lépésben készül tárgykód, ami már a CPU-n futtatható.

    Az "intermediate language" nem futtatható közvetlenül a célgépen, kell valami végrahajtási segéd.
    Ez lehet egy újabb fordító (pl. akár a célgépen), vagy interpreter. És a kettő között számtalan átmenet, a szürke sok-sok árnyalata megtalálható.

    De az én terminologiámban, ha a számtalan alkalommal a lemezről (akárhonnan) betöltött program egy intermediate language és egy motor intézi hogy ez CPU kóddá alakuljon, akkor az interpretálási folyamat. 
    Mégha röptében fordítás is, akkor is, mert a következő alkalommal már megint fordítani kell, nem jelenik meg önállóan futattható programpéldányként.
    Mutasd a teljes hozzászólást!
  • Akkor a GNU C++ fordítója is interpreter, mert hogy az sem egyszer fordít tárgykódra, hanem elõször közbülsõ kódra fordít (RTL) majd abból készül gépi kód. Más kérdés, hogy ezt az rtl-t nem tudja kiexportálni majd az end-user gépén lefordítani a user processzorára.
    Mutasd a teljes hozzászólást!
  • Ha szeretnéd, hogy beléd kössek:

    ami nem egyszer fordít tárgykódra, amit terjesztünk, hanem valami közbenső kódon terjesztett

    A tárgykód lehet köztes is.
    Object code - Wikipedia

    In computing, object code or object module is the product of a compiler. In a general sense object code is a sequence of statements or instructions in a computer language, usually a machine code language (i.e., binary) or an intermediate language [...]
    Mutasd a teljes hozzászólást!
  • még arra is téves az interpreter szó használata

    Az én terminológiámban minden, ami nem egyszer fordít tárgykódra, amit terjesztünk, hanem valami közbenső kódon terjesztett és alkalmanként (mégha cachelve is akár) fordítódik tárgykóddá, na az interpreter!

    A Java motor is egy interpreter, a Dotnet motor is az, mégha ezerszer fejlettebbek már mint annó a basic vagy a p.code (pascal).
    Futás idejű compilerek... de ettől még "interpretálják" az adott CPU-n a kódot csak sokkal hatékonyabb megközelítéssel.
    Mutasd a teljes hozzászólást!
  • WebAssembly-ről van szó. Aminek nagyjából semmi köze a JS-hez.

    Még...
    Mutasd a teljes hozzászólást!
  • Ennyire ne legyél kishitű, az lesz a következő, hogy már a procik mikrokódja is JS-t fog futtani :D

    WebAssembly-ről van szó. Aminek nagyjából semmi köze a JS-hez.
    Mutasd a teljes hozzászólást!
  • Ennyire ne legyél kishitű, az lesz a következő, hogy már a procik mikrokódja is JS-t fog futtani :D

    kb. mint annó a bare metal JVM, akkor is nagyot álmodtak, majd felébredtek.
    Mutasd a teljes hozzászólást!
  • Mi jön még? Kernelmodulok JS-ben? XD
    Mutasd a teljes hozzászólást!
  • Szóval a számtalan interpreter, a JVM és a DotNetCore, Mono, Pascal, stb. bytekód interpereterek mellett a WASM kódját is tudja már Linuxban interpretálni egy alkalmazás. Aha.

    Nem. Az egy másik hír, a Java-s. Bár igazából még arra is téves az interpreter szó használata - de azért az legalább koncepcionálisan közelebb van a klasszikus interpretáláshoz, mint ez. Ami érdekes, hogy ahhoz a hírhez, bár régebbi, nem kommentelted be ugyanezt a lesajnálást. Vajon miért nem? A kérdés persze költői.
    Mutasd a teljes hozzászólást!
  • Szóval a számtalan interpreter, a JVM és a DotNetCore, Mono, Pascal, stb. bytekód interpereterek mellett a WASM kódját is tudja már Linuxban interpretálni egy alkalmazás.

    Aha.
    Mutasd a teljes hozzászólást!
  • LOL ezt komolyan venni ...
    Mutasd a teljes hozzászólást!
  • A fickó az elején lelkesedik, hogy milyen jó dolog kernel módban futni, meg Meltdown. A végén azért ez már csak opció, és az is az eszébe jutott, hogy az örökre-foglalt memória volt a sebesség ára.
    Mutasd a teljes hozzászólást!
  • Miért, ki szeretne Java-s vagy C#-os/.NET-es Hello World-öt futtatni kernel módban? Nyilván semmi akadálya nincs annak, hogy tetszőlegesen összetett/nagyméretű/komplex kódok, programok kerüljenek így futtatásra a WASM-on keresztül.

    Ami ugyanakkor - a natív kódokkal szemben - ugyanabból az egy binárisból tud működni különböző operációs rendszereken és hardverarchitektúrákon is. Ráadásul sokkal egyszerűbben virtualizálható vagy zárható biztonságos containerbe is, sőt, talán ki is lőhető ha lefagy (ami kernel módban nem triviális dolog).
    Mutasd a teljes hozzászólást!
  • Ki ne szeretne wasm-os Hello World-öt futtatni kernel módban?
    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