Säker systemutveckling i Rust
Johan Burell, Valtech
En resa i tre delar
Utmaningar med systemutveckling
En titt på språket Rust
Programmeringsexempel
Men först...
"Hur svårt kan det vara?"
Vårat arv
Våran verklighet
De många lögnerna
De halva sanningarna
Den gyllene medelvägen
Vårat arv
Den komplexa tillståndsmaskinen
Von Neumann-arkitekturen (1945)
"Generell kod fri från hårdvaruförändring"
En CPU med en kontrolldel och en ALU-del
En minnesenhet
Lagring
I/O
Moderna datorer är mycket mer komplexa, men konceptet är detsamma
En av flera nackdelar med arkitekturen är flaskhalsen mellan minne och CPU då bussen inte ändrats i samma takt
Andra arv: CISC, IBM-PC kompatibilitet, centralisering...
Våran verklighet
Vad betyder "minnesallokering"?
Från vem? Hur?
Vad ser vi när vi tittar på värdet av en pekare?
VM (i en container... i en annan VM...)
OS
MMU
Hårdvara
Ett modernt system har så många lager av abstraktion så att hela stacken kan tyckas vara virtuell
Indirektion = cacheat tillstånd
I en lång kedja...
Vad är
egentligen
värdet på din variabel?
Samtidighet
Ett nödvändigt ont för att frysa tillstånd i en föränderlig värld
Hur hanterar vi hastighet och korrekthet?
På hårdvara
Fler kärnor för parallell exekvering
Mer minne för mindre "tävlan"
På mjukvara
Lås (mutex, 2-phase commit, CAS etc...)
Duplicering (CoW, meddelanden etc...)
Synkronisering, bieffekter...
Komplex kod
Långa lås saktar ner exekvering
Väntan på resursers tillgänglighet
Stor risk för deadlocks/livelocks
Latens
Otroligt svårt att testa tillförlitligt
Duplicering, bieffekter...
Stor mängd allokeringar
Olika strukturer har olika nyttjande
Referensräkning
Komplexa datastrukturer och städare
Transaktionsmodeller
Väldigt stor mängd Cache-missar (ist.f. DOD)
De många lögnerna
"Minneshantering är löst"
... genom att inte hantera det.
ingen delning, ingen tävlan...
... genom att betala dyrt för att någon annan löser det
garbage collection, smarta pekare...
... förutom att tillstånd fortfarande är ett bekymmer
allokering är bara det lilla problemet...
... vilket gör att vi behöver 16-32GB minne att göra vardagssysslor
RAM för samtliga 61 miljoner NES spelmaskiner som såldes uppgår till knappa 122GB tillsammans
"Datorer är snabba nog!"
... men det är ju synd att nyttjandet är så lågt.
blocking I/O, cache missar...
... men det är ju synd att mjukvara är så ineffektiv
enkeltrådat, indirektion av minne, tolkade språk...
De halva sanningarna
Utvecklartid vs exekveringstid
... men hindrar ju inte att man kan få båda
En del problem som löses har vi skapat själva...
... men det är påfrestande att känna till detaljer
Dolda beteenden tenderar att bubbla till ytan och bli dyra eller omöjliga att göra sig av med...
... men mätes inte bara i rader skriven kod.
De riktigt dyra kostnaderna visar sig först när man behöver
läsa
koden...
Lämna de svåra problemen till experter och biblioteksutvecklare
... men även små mängder dålig kod kan haverera system
Systemutveckling är dessutom en lagsport...
... men ineffektivitet är inte ett lokalt problem
Se bara utmaningarna med systemintegration/akitektur
... men även experter snubblar regelbundet
Heartbleed, goto fail, AWS S3 haveriet 2017...
FP gör koden "felfri"
... men exekverar långsamt
Haskell ex är ung 2-10ggr* så långsamt som C på flera algoritmiska problem
... men slösar med minne
Haskell drar mer än dubbelt* så mycket som C för många liknande uppgifter
... men är svår att sälja in till juniorer/kunder/"veteraner"
Nya (eller nygamla) språk har alltid uppförsbacke, även Rust...
*Syntetiska tester på https://benchmarksgame-team.pages.debian.net
Den gyllene medelvägen
Önskelistan
Betala bara för det du använder (C/C++)
Hårdvarunära
Uttryck istället för statements (FP/dynamiska språk)
Kraftfullt typsystem (statiskt med stöd av ADT)
Regler för minneshantering, med språkstöd (RAII, immutable, ADT)
Made with Slides.com