Jens Peter Karlsen skrev:
Det ser ikke ud til at du har meget forstand på hvad du taler om.
Det er helt fint at du gerne vil komme med din mening, men til en anden gang bør du sætte dig lidt ind i grundlæggende begreber om hardware design og Operativ system design.(Så undgår du at blive helt til grin)
Til det sidste kan jeg anbefale at læse Tanenbaum's "Distributed Operating System"
Et operativsystem, har en operativsystemkode, som er abstrakt, og uafhængig af hardware. Kun hardwaredrivere definerer grænsefladen til hardware. CPU driveren, defineret interfacet til CPU'en. Den er den eneste komponent under operativsystemet, som indeholder CPU afhængigt kode. Det er en defination.
Microsoft, og Linux, har ikke en sådan arkitektur. De har ikke noget operativsystem sprog, og det betyder, at de ikke oversætter koden de udfører til hardwaren. I praksis, giver dette et langsommere og dårligere operativsystem, og det kræver ustandseligt nyt software, fordi der kommer mere ram, og mere CPU og flere bits og større harddisk. Det er faktisk ikke rigtigt et operativsystem. Det er nærmere en form for et neddroslet operativsystem, hvor der ikke er nogen CPU driver, og hvor andre væsentlige drivere måske også mangler. Normalt, er også en intelligens komponent indstalleret, som muliggør at koden "forstås" fremfor udføres. Denne mangler også.
Et rigtigt operativsystem, har sit eget operativsystem sprog, og dette sprog er abstrakt. Det er et sprog, som let lader sig oversætte til enhver form for CPU, og enhver form for parallelitet. Det har ikke arvet nogle af hardwarens begrænsninger, såsom 32 bit, eller lign. Der findes ikke 32 bit eller 64 bit integers - bare fordi det findes i hardware. Eller en begrænset addressebus, til et bestemt antal bits. Et rigtigt operativsystem, er altså ikke 32 bit, eller 64 bit. Det er komplet umuligt. Det er kun CPU'ens driver, som er det, eller rettere beregnet for en CPU som er. At kalde det 32 bit, på grund af CPU'en svarer til du kaldte det S/H på grund af et monochrome grafikkorts begrænsninger. OK, hvis man så tvinger til brugen af et bestemt grafikkort, så er det noget om det?. Og det er netop hvad Microsoft gør. Men generalt set, er det forkert. Et operativsystem, er uafhængig af CPU, og hardware. Det er operativsystemets drivere, der beskriver grænsefladen til hardware, herunder CPU'en. Og kun dens CPU driver, må indeholde CPU kode.
Hvis vi tager et problem, som en 32 bit processor, hvorpå vi kører kode med 64 bit arkitektur (samme princip ved uendelig bitbredde som er det korrekte), så sker det ved, at man sorterer anvendelsen af hukommelsen så små sammenhængende blokke placeres i starten, og kan slås op indenfor de første 31 bits, uden ekstra overhead i koden, da de er indenfor den del hardwaren håndterer. For de dele, der anvender meget lager, placeres de senere i det virtuelle addresserum, og noget ekstra kode, som den dynamiske compiler genererer, gør at addresserummet udvides til uendeligt. Antages, for nemhedens skyld, vi udvider til 63 bits, så kan vi gøre det ved vi har en tabel, hvor de øverste 32 bit huskes, og som vi slår op i, afhængig af hvilken blok vi har fat i. Dennes værdi tjekkes med de pågældende bits for addressen, så vi undersøger om det er cache miss. Cache strukturen realiseres altså i software, af den dynamiske compiler. Koden for et sådant tjek, er kun ganske lille, og tager ikke lang tid. Den indsættes automatisk af operativsystemet ved brugen, så det er ikke noget programmøren opdager, eller har adgang til.
Der findes ikke nogen egenskaber, fra CPU'en, som må "arves" til operativsystem sproget. Operativsystem sproget, er uafhængig af CPU, harddisk størrelse, netværk, osv. og fungerer med uendeligt størrelse. Sådan er det. Det kan ingen bøger omdeffinere, med mindre de har forstået noget meget dårligt (måske efter at have lært noget forkert i gymnasiet).
Rigtige operativsystemer, der håndterer parallelisme ordentligt (som udfra abstrakt program beskrivelse automatisk paralleliserer til det aktuelle til rådige antal CPU'er), kan kun fungere med en dynamisk compiler, eller noget tilsvarende implementeret i hardware. Det betyder, at man i praksis ikke anvender operativsystemer som Microsofts, og Linux til større opgaver. Software, skrevet til disse operativsystemer, lader sig ikke automatisk parallelisere nemt.
Idag, foregår masser af forskning, netop i paralleliseringen og scheduleringen, som foretages af den dynamiske compiler. Og forskningen viser, at disse dele, kun kan gøres af en dynamisk compiler i operativsystemet, og at det ikke er muligt som statisk compilering, eller egnet til implementering i hardware. Derfor, kan man i praksis ikke lave operativsystemer der håndterer parallelisme korrekt, hvis det overlades til hardwaren. Det skal gå via operativsystemet, og den vil så i samarbejde med CPU driverne stå for parallelisering og implementeringen på den pågældende struktur.
Mange tror, at et operativsystem er brugergrænsefladen med ikoner. Et operativsystem, har ikke meget med det at gøre. Operativsystemet, er i virkeligheden en underliggende arkitektur, som muliggør at du kan abstrahere koden, på et højere niveau, og få den til at virke med en bred bunke hardware og processor strukturer. Du vil kunne udskifte hardware, CPU, tilføje nye processorer osv. på grund af operativsystemet. Det er formålet. Derudover, har operativsystemet, en række sikkerhedsmæssige funktioner, som i øvrigt også indbygges nemt, når det er baseret over en dynamisk compiler.
Nogle forbinder Java, med dynamiske compilere, og operativsystemer der anvender dynamiske compilere. Java byte kode, er dog ikke egnet som operativsystemsprog, da det ikke lever op til kravet om hardwareuafhængighed. Idéen har været at beslutte en hardwaremaskine (JVM), fremfor at lave et sprog, der er egnet til kompilering til enhver form for hardware. Java byte kode, er ikke egnet til compilering til enhver hardware struktur. Som eksempel, er det begrænset på bitbredder mv. ligesom en Intel CPU, og det er en metode, der ikke tillader effektiv oversættelse, fordi man ikke kan analysere fra en begrænset bitbredde og implementere det automatisk på større bitbredde genneralt. Javas bytekode, bryder dermed med en af de vigtige love, om at man ikke må arve ting fra hardware arkitekturen, herunder en besluttet og hardware arkitektur, og det er derfor ikke egnet som operativsystem sprog, da det ikke overholder "loven".
Processorer tilbage i 70'erne kunne mikrokodes, således de som maskinkode, anvendte højniveausprog, eller operativsystem sprog. Senere, er man begyndt at bruge dynamiske compilere, og moderne operativsystemer har også et plugin der muliggør intelligent udførsel af indstruktionerne, således koden analyseres og planlægges langt ind i fremtiden, under hensynteagen til cache osv. Der kan også laves reduceringer på koden, så hvis noget kode står og gør det samme uafbrudt, kan det opdages og måske fjernes. I nogle tilfælde, er resultater som ikke bruges, og der automatisk kan elimineres bort. Alle disse dele, foretages af den dynamiske compiler, under forståelsen af operativsystemkoden, og oftest kan det gå mange gange hurtigere, end på en PC med "Windows" og "Linux".
Et godt eksempel, er fortolkere og compilere. Her viser det sig, i nogle tilfælde, at fortolkere bliver ligeså hurige som compilere, hvis der er mange CPU'er til rådighed. Selve flaskehalsen, i den fortolkede kode, er den samme, og er der CPU'er nok, vil hastigheden for en fortolket og compileret kode være ens. Paralleliseringen medfører altså, at hastigheden er ens.
Det viser sig også, at visse af processerne udfører ganske trivielle jobs (specielt fortolkerkoden), som kan rationaliseres bort. Og dermed, kører computeren faktisk hurtigere. Det er også muligt, med registeroptimeringer, og forskellige andre optimeringer i et intelligensmodul. En compilers effektivitet, betyder således mindre. Med tiden, forventes at intelligensmodulerne bliver mere kloge, og kan direkte løse matematiske og datalogiske opgaver, på helt anden måde - måske så bobbelsort automatisk omskabes til fletsort. Eller det, der er værre. Nogle frygter endog, at intelligensmodulet bliver for klogt, hvis den engang selv får lov at opdage reduktionsmetoder, der gør koden udføres hurtigere, måske sammen med andre operativsystemer og computere i store netværk. Måske kan de "stjæle" andre computeres matematiske viden om en opgave, og anvende denne i deres udførsel hvor en opgave løses.
Log ind
Publiceret d. 1. juli 2008 kl. 15.56
| 
