– C++ er på mange måter det mest praktiske språket jeg vet om (Ekstra)

[Harald Brombach (digi.no)]

Vi har slått av en prat med utvikler Lars Thomas Hansen, som jobber i WebVM-gruppa hos Mozilla.

– C++ er på mange måter det mest praktiske språket jeg vet om (Ekstra)

[Per Buer]

Spennende.

 

Jeg har ingen ide om Lars leser denne saken eller ei, men hvis du leser den så hadde det vært moro å høre med noen som jobber på Webassembly om hva de synes om min litt sprø ide om bruk av små virtuelle maskiner og unikernels som et alternativ til webassembly. http://unikernel.org/blog/2017/the-search-for-the-killer-app-of-unikernels

 

Jeg må med hånden på hjertet si at jeg ikke vet så skrekkelig mye om webassembly og detailjene rundt det så det er ikke utenkelig at det er noe jeg ser. Først og fremst er vel styrken til webassembly full støtte for andre platformer. En unikernel-approach vil jo være CPU-spesifikk. Med mindre en kan gjøre oversettelse til andre arkitekturer så vil det derfor være litt upraktisk.

[DF4QRNUD]

I’m not certain about why Google decided to discontinue NaCL; they’re a bit opaque on why.

 

Ingen andre browsere ville så mye som ta i NaCl / PNaCl... (Jeg var ikke på innsiden av den diskusjonen men det var litt teknologi og litt politikk.  På den teknologiske sida tror jeg ikke engang PNaCl var så portabel som man skulle ønske, spesielt ikke over tid.  Og endel av greia med wasm er at koden er veldig kompakt og komprimerbar, dette har vært et eksplisitt mål for å gjøre wasm på den mobile webben konkurransedyktig.)  Og så sprang ideen om webassembly ut av arbeidet med asm.js, som det var mer interesse for, og som hadde vist seg som en farbar vei.  Og de fleste av oss er antakelig tjent med en teknologi som forvaltes i fellesskap og ikke kontrolleres av ett firma.

 

Artig det du skriver om Unikernel.  Lettvekts kjerner er en ide som kommer og går, sjøl hørte jeg først om ideen i Engler og Kaashoeks paper på exokernel (ca 1995), kanskje ikke akkurat det samme men beslektet.  Det du beskriver er mye som webassembly ser ut i dag: det er en boks som kjører inne i browseren, du kan kalle inn i boksen og kalle ut av boksen, og du kommuniserer med boksen stort sett ved å endre ting i et delt minne.  I prinsippet kjører boksen i et helt adskilt og beskyttet miljø og har ikke adgang til minnet i prosessen rundt seg.  Så er spørsmålet om denne bør være i en egen virtualisert prosess eller ikke... 

 

For å nerde litt om det, på 64-bits systemer reserverer vi 6GB addresseområde for hver wasm-instans, slik at vi kan bruke CPUens innebygde boundschecking og slipper å ha en sjekk for hver minnereferanse.  På denne måten kommer ytelsen ganske nær native selv med full sikkerhet.  På 32-bits systemer er ikke dette mulig og ytelsen er tilsvarende noe dårligere.  Vi har diskutert om vi kan kjøre wasm i en egen prosess (og således komme enda nærmere unikernel-ideen) men da støter vi mot et annet problem:

 

Vi ønsker nemlig å ha /rask/ tilgang til DOM og /raske/ kall inn og ut av JS, og det er egentlig tvilsomt om vi kan ha det uten å kjøre i samme prosess.  Jeg tror dette er et vanskeligere problem enn du beskriver i din artikkel.  I tillegg kan vi, ved å bruke typesystemet i wasm, garantere at data er safe og at det ikke er noen forvirring om hva som er en peker til et DOM-objekt og hva som er en integer, for eksempel.

 

Uansett, ett område hvor unikernels har en fordel er at de kan kjøre native kode med alle instruksjoner som CPUen kan by på - det kan ikke webassembly.  Vi støter allerede mot noen av problemene her i forbindelse med SIMD-instruksjoner som kommer etter hvert, for her er x86 og ARM ganske forskjellige og det er vanskelig å ha ett portabelt instruksjonssett som dekker alle CPUer på en fornuftig måte.  Og hva med AES-instruksjoner og tilsvarende godbiter?  Så selv om wasm og unikernels er nært beslektet på mange måter er trykket hos wasm på noe som er stort sett portabelt og som fungerer best i et miljø som kan fylle inn tomrommene i wasm (istedet for AES-instruksjoner kan du kalle ut til WebCrypto), ikke noe som gir ubegrenset tilgang til CPUen.

[Per Buer]

Supert. Det bar masse mening. Unikernels-begrepet stemmer kommer overens med Exokernels, forskjellene er vel at en exokernel skiller på applikasjon og kjerne. Mens i en unikernel så kjører alt i et enkelt adresserom. 

I utgangspunktet var vel unikernels vanskelig å realisere direkte på maskinvare uten å ha noe magi som gir deg mulighet til å oppdatere og vedlikeholde applikasjonen din. Unikernels-tanken ble født etter at hypervisorene hadde gjort virtualisering tilgjengelig og en kan gjøre utrulling og slikt gjennom hypervisoren sine grensesnitt. Dermed kunne en ta exokernel-tankegangen enda lenger.

IncludeOS kan i og for seg kjøre direkte på maskinvare. Vi har kommet et stykke lenger enn Engler/Kasshoeks var i '95 og vi har idag noe som etterhvert vil kunne la oss kontrollere en unikernel kjørende direkte på maskinvare. Liveupdate har vi kallt det og etterhvert kan kommer vi sikkert til å publisere noe rundt det.

Du har helt rett i at en unikernels-approach vil legge på overhead tilsvarende IPC når den skal snakke med DOM.