Software halter håbløst efter hardware

Et sprog, der udfører indstruktionerne i rækkefølge, er nemt at forstå, og har egenskaber i retning af determinisme og reproducerbarhed.

I parallele sprog, ses ofte, at der anvendes stokastiske metoder, når to tråde, skal have adgang til samme enhed. Hvis adgangen styres stokastisk, er det meget svært at reproducere softwarens funktion, og med blot en mindre grad af frihedsgrader på dette risikeres usikker og ustabilt software.

Samtidigt, er uønskeligt, at programmøren skal opdele programmet i X antal parallele processer, som svarer til hardwaren. Året efter, kommer hardware med flere paralle processer, og den gamle software er forældet. Det ideelle - og eneste korrekte, er at et program er abstrakt i forhold til hardwarens parallelisme.

Derfor, skal programmer ikke opskrives parallelt. Parallelismen i et program giver ingen betydning. Det er operativsystemet, kompiler, og hardwaren, der har som opgave at stå for at mappe opgaven ind i den givne struktur. Får du en ny processor, er krav om, at den gamle software stadigt kører optimalt. Optimaliteten må ikke afhænge af, om du kører flere programmer samtidigt eller ikke. Brugerne kræver, at softwaren altid kører optimalt.

Det er muligt at opnå at software beskriver det job der skal udføres - og ikke parallelismen i denne opgave. At mappe softwaren ind i parallelisme er computerens opgave, og det er en del som bedst hører under operativsystemet.

Derved kan computeren udstyres med flere CPU'er, endog meddens den kører, f.eks. via netværk, og hastigheden øges. Eller, der kan sættes flere moduler i. Operativsystemet, skal udfra det program den skal udføre, være i stand til at dynamisk være i stand til at tage højde for hardwareudvidelsen, og at tilpasse softwaren til de nye krav. Det betyder at den skal opdeles i flere processer - eller færre - hvis et eller flere moduler sætter ud.

Når sideløbende programmer paralleliseres og denne parallelisering skal mappes ind på en processor der håndterer færre tråde, end paralleliseringen fører til, er også vigtigt at denne indmapning sker optimalt. Det betyder, at nogle processor må prioriteres over andre, af hensyn til f.eks. hardwarekrav, optimering af hardwareresourcer såsom ram, eller for at minimere svartiden overfor bruger.

Idéen er derfor ikke væsentligt i nye programmeringssprog, men at kunne datalogi nok, til at analysere software, således man kan lave et operativsystem. Netop kompatiblitet med hardware (forskellige processorer, og parallelisme), er nogle af de vigtigste grunddele af et operativsystem. Desvære, er der mange operativsystemer der bryster sig af at være operativsystemer uden at rumme disse dele, hvilket egentligt kan betvivles om de er.

Hvis man skulle vælge Erlang - eller et at andet sprog, for programmering har det intet med parallelismen at gøre. Det som er interessant for et programmeringssprog, er dets evne til, at få programmøren til at programmere fejlfrit. Her kan muligheden for at beskrive noget parallelt måske være en fordel for programmøren. Men, det er alene et sprogs sikkerhed, og evne til at kunne fortælle programmøren når han lavet noget der ikke er konsistent, som er væsentligt. Der er forskel på, hvor mange fejl, at programmeringssprog fører med sig - og hvis at noget overhovedet skal fungere i et større program, har programmeringssproget en utrolig vigtig status i forbindelse med at minimere eller undgå fejl. Det største problem for software i dag er programmeringsfejl. Parallelisme er kun interessant, hvis det viser sig, at ville kunne få programmøren til at lave færre softwarefejl, f.eks. ved at kunne simplificere opgavens beskrivelse. Typisk tager fejlfinding og retning i dag langt længere tid, end at udvikle softwaren, og det er at reducere denne tid, som er væsentligt, når der udvikles programmeringssprog. Nogle opgaver beskrives dog bedst parallelt, og jeg tror på, at sprog som Erlang måske er bedre end C.

Et højniveau sprog, er deffineret ved at abstrahere sig fra hardware. Det betyder, at hardwareegenskaber som bits, regnenøjagtighed, CPU indstruktionssæt, og antal CPU'er, ikke er parametre der må indgå i højniveau sprog. Sproget bruges, til at beskrive en opgave, og compileren samt operativsystem og computer, har opgaven at mappe opgaven ind på hardwaren. Compileren laver den statiske behandling, og finder de fejl der kan findes så tidligt som muligt, meddens operativsystem og hardware laver den dynamiske behandling. Normalt vil vi gerne have så meget som muligt under den dynamiske behandling, da det gør programmet fleksibelt og den oversatte kode kan bruges til mange forskellige CPU'er, og med forskellig grad af parallelitet.

Software har i lang tid haltet efter hardwaren. Det er en grundliggende misforståelse at man skal abstrahere fra sin hardware. Kode er jo ikke bare kode. Man må starte med at finde ud af hvad der kræves af den SW man arbejder med. Der er selvfølgelig noget funktion, men der er næsten altid en masse mere eller mindre skjulte krav som først skal klarlægges. Disse krav er ofte relateret til hardwaren.
De bedste software værktøjer er dem som giver dig mulighed for at få overblik over hardwaren og netop udnytte den givne platform til at få løst opgaven. Det er ikke anderledes med multiprocesser systemer.

Som specialist indenfor det embeddede område kan man kun ryste lidt på hovedet af denne "nyhed". Det er altså ikke sproget der er det vigtigste, det er vigtigere at man modellerer rigtigt.

For 20 år siden var modelleringssproget SDL rigtigt hot, specielt i danske telekommunikationskredse. SDL benytter netop seperate processer som kommunikerer via nogle primitiver.

På baggrund af dette lavede vi således et operativ system der understøttede netop disse primitiver, og med fuld data seperation mellem processerne baseret på MMU.

Jeg har således være med til at designe et embedded system hvor målet var at der skulle kunne afvikles 2.000 kommunikerende processer. Men der var altså kun 8 MB RAM til rådighed.

Senere har vi så skiftet til Linux, men vi har bibeholdt modelleringen, og blot lavet et C++ API som implementerede primitiverne og erstattede processerne med tråde. Men formelt er det stadigt forbudt at dele variable.

At vi har valgt at lave den slags trade offs, skyldes ene og alene at vi skal holde prisen nede og derfor ikke bare kan svine med RAM og performance i den enkle CPU som vi har.

Jeg tror at der går mange år før vi ser multicore hardware i embeddede systemer, men modelleringen vil helt klart skalere. Bare vi har et OS som kan understøtte en effektiv kommunikation mellem processerne.

Desværre så table SDL den kommercielle kamp til UML, der også kom i en realtime version i form af Rose Realtime. Ulempen ved RoseRT er at den nærmest opfordrer til at man skriver i gammeldags C eller Java nedenunder modellen.

Jørgen Henningsen skrev:
Det er en grundliggende misforståelse at man skal abstrahere fra sin hardware.

Det afhænger meget af opgaven. Kommunikeres som eksempel med en printer, bliver du nød til at kende protokollen.

Abstraktionen mellem software og hardware i højnivau sprog gør, at du kan flytte programmet fra en computer til en anden - trods den har anden printer, og anden CPU. Det er bestemt meget vigtigt, og ikke en grundlæggende misforståelse.

Operativsystemet, er her den del, der sikrer kompatibiltiet med hardware.

Embeddede systemer laves ofte til specielle formål og behøver ikke et operativsystem. Det kan accepteres at der skrives direkte til hardwaren. Der er ingen fleksibilitet, og intet krav at nyt software fra 3. part kan indstalleres. Ofte vælges dog at have et simpelt operativsystem.

Fordelen ved højniveau sprog, fremfor C og assembler, er at højniveausprog abstraherer sig fra hardwaren. Det er sproget, der angiver funktionen, og sproget fungerer ens uanset hardware. Trods programmet flyttes til anden CPU, vil den fungere ens. Operativsystemet deffinerer omgivelserne, og sproget deffinerer primært input og outputs til operativsystem. Operativsystemets opgave, er at stå for tilpasningen til enhver type hardware. Bruges det samme operativsystem, og er f.eks. printere indstalleret, bør det virke ens, uanset fabrikat. På samme måde, kan CPU erstattes, med anden indstruktionssæt og det er operativsystemets opgave at stå for oversættelse til den pågældende CPU. Sproget mellem compiler og operativsystem, er holdt på et niveau der ikke er hardwarenært, da oversat kode så ikke kunne bruges.

Sprogmæssigt, betyder dette, at det på ingen måde må kunne skrives et program i højniveau sprog (eller det "maskinsprog" der bruges mellem højnivau sprog og operativsystem) der kan opdage hvilken type hardware der bruges. Svaret skal altid være ens. Hvis derimod at der ingen printer findes, og programmet kræver printer, skal operativsystem gøre opmærksom på dette. "Maskinsproget" mellem operativsystem og højnivausprog, har som opgave, at sikre programmet fylder minimalt, og er analyseres på forhånd, så det nemmest og hurtigst oversættes af operativssytemet til CPU og hardware.

Et OS der understøtter effektiv kommunikation mellem processerne, vil bedre kunne analysere det, hvis det får processerne som det består af - altså programmet overleveret. Du kan relativt nemt lave et program der står i rækkefølge til parallelisme. Men, du får mange millioner af processer, hvor nogle af disse kører afhængigt af hinanden - meddens andre kører uafhængigt. Skal parallelismen udføres effektivt kræves analyse af, hvad der udføres afhængigt og uafhængigt, og i nogle tilfælde skal analysers hvilke dele der fører til bestemte outputs.

Denne analyse er svært at gøre i operativsystemet, hvis du ikke får programmet. Nogle dele af analysen kan gøres i compileren, før det lægges i kode til operativsystemet, men det kan være mere sikkert at gøre i selve operativsystemet, da man ellers risikerer at jobs accepteres som uafhængige og kræver langt større resourcer at håndtere, end nødvendigt. Håndteringen vil typisk være, at compileren oversætter til kompakt kode, der fylder lidt, og kan udpakkes under udførsel, og at operativsystemet herefter analyserer koden, med henblik på parallelitet.

Min påstand er, at et operativsystem ikke kan håndtere parallele tråde effektivt, hvis det ikke får oplysning om hvorvidt de parallele processer er afhængige eller uafhængige. Denne oplysning kan gives af enten compileren, eller opdages af operativsystemet, ved den analyserer koden før den bruges. Denne analyse, kan foretages i små bider, efterhånden som softwaren kører, og opbevares på harddisken så den ikke skal foretages unødigt. Samtidigt sikres kompatibilitet til enhver hardware parallelisme, og CPU type, udfra en CPU driver.

Der indsneg sig et par fejl i ovenstående. Analysen kan ikke foretages i små bider normalt.

Det er godt fordi som du skriver så kan man portere sin kode. Det er også skidt fordi man slipper forståelsen for hardwaren. Man ser det hele tiden indenfor PC verdenen. Programmerne bliver større og større og tungere og tungere og fordi man ønsker et meget højt abstraktionsniveau og ikken alene hardware abstraktion, men også abstraktion fra operativsystemet.
I den sidste ende er det et spørgsmnål om strømforbrug. Jo mere man svinekoder uden at forstå hvad det er for nogle tidsmæssige resoucer man beslaglægger, jo tungere bliver progammet. Det er jo det dejlige ved sådan noget PC kodning. Kører din kode for langsomt, så bestil en hurtigere PC.
Jeg er egentlig lidt ligeglad med om det er operativsystemet, compilerextensions eller Carla Klovn som håndtere multicore arkitekturen, det kan man for min skyld gøre som man vil. Jeg insistere bare på at jeg bliver nødt til at vide hvad det er for nogle ting, som min kode sætter igang og hvad det ca. tager af tid.

Jeg er helt enigt med dig i, at vi skal vide hvad vi sætter i gang når vi udfører en ordre. Måske udvikles en kæmpe varme og millioner af indstruktioner udføres - eller der udføres kun en enkelt maskinindstruktion. Der bør være datablade for sprog, som indikerer et mål for antallet af indstruktioner der udføres, og indstruktionens kompleksitet.

Dette er svært, når du samtidigt får et operativsystem, der arbejder med koden. Ikke desto mindre, bliver koden ofte langt mere effektivt. Hvor du i dag typisk kalder en ordre i operativsystemet, for at foretage et output, så kan operativsystmet vælge at sætte outputtet direkte ind i din kode. Det gør, at det bliver effektivt. Der skal ikke laves hop til helt andre steder i lageret, for at udføre noget simpelt, såsom task skifts. De kan klares ved direkte at opsætte stack pointer, og skifte task, og ved at push/poppe minimalt, eller ved at bruge CPU features direkte i den oversatte kode. Koden fylder tilmed ikke væsentligt mere, da den "udpakkes" fra originalkode, og opbevares i en cache - og det er kun i cachen at den fylder.

Jeg tror også, at det er muligt, at angive et tal for kompleksitet. Forsinkelser mv. bør kunne styres af operativsystemet, og den skal kunne stå inde for, at timing opfyldes.

Vi bør også uddanne dataloger og programmører, til at forstå, hvad der egentligt foregår internt i computer og operativsystem, så de faktisk kan stå inde for, at metoderne fungerer.

Men - der er en kraftig ulempe. Tingene bliver uhørt komplicerede. Og skal du lave noget sikkert, hvor du virkeligt ved det fungerer, vil jeg ikke anbefale et advanceret operativsystem, med masser af ovenstående finurligheder. Derimod, en simpel compiler, der oversætter til assembler, og hvor du har manuel mulighed for, at verificere at assembler koden, og det du har indtastet er overens. Samtidigt er her nemt at opskrive tal for hvor mange indstruktioner der udføres for hver enkelt sprog i højnivau sproget.

Et højniveau sprog, er dog så vidt muligt hardware uafhængig og CPU uafhængigt. Datablade for antal indstruktioner der udføres, er et compilerdatablad og har ikke noget med sproget at gøre. Hvis du undgår operativsystemet, og sender koden direkte til hardware, er det intet i vejen for at bruge et højniveau sprog. Du vil stadigt kunne flytte programmet, til en anden CPU, og en anden hardware struktur - dog sættes krav om samme input/outputs og hardware kompatibilitet for den del af hardwaren du har lavet kode for. Et højnivau sprog, kan godt bruges til HW driverne i et operativsystem, og højnivau betyder her kun, at det er CPU uafhængigt. Du vil kunne flytte din HW til en anden computer, med andet indstruktionssæt, og stadigt vil det fungere.

Hvis et bibliotek indeholder standard UDP og TCP lag mv. og dit hardware sættes på nettet, vil din kode kunne flyttes til enhver anden computer uanset indstruktionssæt, men den vil være skrevet til kommunikation med dit hardware, efter den pågældende protokol, som du har valgt. Vi skal måske forvente, at HW i fremtiden sættes på nettet, og denne metode, er den rette at skrive software til HW på. Tastatur, mus, og display, kan også sættes på nettet, og giver tilsammen en såkaldt terminal.

Jeg tror på, at vi behøver to form for kodesprog i fremtiden: Den jordnære, tæt på maskinsprog, hvor der ikke sker mystik med koden, og hvor vi umiddelbart kan gennemskue sammenhængen mellem det vi indtaster, og outputtet vi får. Det giver sikkerhed, og vi er rimeligt sikker på, at compilerne gør korrekt, og ikke indeholder bagdøre mv. Vi kan selv verificere vores kode, og vi kan skrive alt kode fra bunden, eller bruge noget, som er overskueligt, og hvor vi er sikker på, at det ikke indeholder forkert kode. Sproget her, vil måske være C, på grund af dets effektive og simple oversættelse, meddens C++ måske er for kompliceret.

Vi får derudover brug for et højnivausprog, som er mere abstrakt. Det er egnet for, at mange mennesker arbejder på samme opgave. Der anvendes operativsystem, som garanterer effektiv adskillelse af programmørernes arbejder, og det er muligt at debugge og bestemme hvilken programmør der eventuelt gør forkert. Typisk vil operativsystemet indeholde dele af en compilers opgaver (det som rummer dynamisk compilering), og kunne tilpasse koden til computeren, samt til dens grad af parallelitet som computerens hardware give til rådighed. Den vil kunne samarbejde med andre computere, om at dele resourcerne.

Vi vil nok se tendens til, at programmørerne går mod det advancerede og den sidste løsning, trods man ikke har helt samme vished for, hvordan tingene fungerer. Men, det er vigtigt, at der findes godt og grundig dokumentation for hvordan det fungerer, og at man skal kunne læse denne, og faktisk vide det som egentlig sker. Det er dog advanceret, og svært at tjekke. Men, det må ikke ske fejl, og for de pågældende dele, vil man kunne afsætte mange millioner mandeår om nødvendig, for at opnå det ikke er fejl. En fejl, i de grundlæggende dele, er så fatal, at det ofte vil føre til altødelæggende resultater, og samfundet har ikke råd at betale. Man vil kunne kræve, at de virksomheder der har udviklet grundsoftware som ikke fungerer lukker, og gør deres forskning fri, da de ikke har råd at betale de udgifter, som de har påført os alle. At bruge en milliard mandeår, er småtting i forhold til konsekvens.

Derfor, er den simple løsning ofte at foretrække. Vi ved det fungerer. For det er så nemt, at vi kan forstå det. Og jeg vil nok også foretrække den hardwarenære og simple løsning, hvor udvikleren har fuld kontrol med koden fra højnivausprog til assembler, og til bits, fremfor en advanceret løsning, hvor vi risikerer at stå med et kæmpe problem, fordi nogen ikke gjorde deres job godt nok, eller at der var politiske årsager, til at gøre hele verdens computeranlæg deffekte.

Hvis jeg skal acceptere et dankort, eller lign. vil jeg uden tvivl føle mig mest sikker, hvis jeg ved programmørerne kender enhver linie - også i maskinkode, og bits i kredsen, og kan stå straffemæssigt indefor at det fungere. Hvis det er den advancerede løsning, ender alt med en omgang fis, hvor ingen kan finde ud af hvor ansvaret placeres. De skylder blot skylden på hinanden i det uendelige, fordi ingen tager ansvar, og resultatet bliver enighed om at det er så kompleks at ansvar ikke kan tages.

Simple løsninger, hvor programmøren er hardwarenær og verificerer sin kode er korrekt efter oversættelse, er ofte mere sikkert.