Næste skridt
må vel være reducering af antallet, lave dem mere kompakte, det vil gøre energiforbruget mindre og give muligheder for at øge hastigheden markant.
Mængden af transistorer må kunne reduceres med boolsk algebra, eller lignende. Ingen skal bilde mig ind at 100 millioner transistorer er en nødvendighed, der er uden tvivl masser af inaktive kredsløb, som kan fjernes til en start.
Det er ikke så svært at reducere antallet af transistorer – men ofte går det ud over hastigheden. Går vi nogle år tilbage, så brugte Intel et stort antal transistorer i forhold til funktionaliteten. Laver du en CPU på en FPGA, så vil du opdage, at en Intel processor, på grund af dens komplekse instruktionssæt, meget nemt fylder mere, og bliver langsommere, end en Mikrochip PIC kompatibel cpu. En PIC kompatibel CPU kan som regel køres med halvdelen af frekvensen af BRAM’erne, og er du dygtig, kan du nemt få den højere op. Typisk, er det en frekvens på over 150 MHz, uanset om den laves som 8 bit, eller 16 bit, og med en instruktion per klok. Laver du en Intel Pentium kompatibel, så vil du få problemer med at klokke den ved over 25 MHz. Alene grundet CISC instruktionssættet. Intel “løser” problemet, ved at bruge masser af transistorer. Deres instruktionssæt oversættes internt til en slags RISC / PIC instruktionssæt, og caches, før det kører videre. Ikke kun denne oversættelse koster transistorer, men skal det køre med optimal performance, så er også nødvendigt med stor cache intern på CPU’en.
Udover cache, så kan du ved brug af mange transistorer opnå, at selve ALU’en går hurtigere. Prøv at forestil dig et program, der f.eks. indeholder en løkke – du har mulighed for, at folde denne løkke ud. Omtrent det samme gælder for hardware. En CPU kan betragtes som et lille program, der henter en instruktion ind, og udfører den. Udfoldes denne løkke nogle trin, så kan du hente flere instruktioner ind på en gang, og udføre dem samtidigt – det smarte er, at du også kan forwarde data direkte kombinatoriske mellem disse beregningsenheder, og det viser sig så, at det går hurtigere end du kan forudsige. Det, som du kan forudsige er, at hvis der ikke er afhængigheder, så vil det gå hurtigere – men, trods det er afhængigheder, så går det faktisk også hurtigere. Hvor meget, kan du dog ikke forudsige, med mindre du ved eksakt hvad programmet gør. Antager vi eksempelvis, at du har en ribbel-adder, så skal du vide om du lægger 3 til 4 eller 3 til 253, for at vide hvor hurtigt operationen er. Selvom du bruger look-ahead typer, så er der tilsvarende problematikker, når flere operationer udføres samlet – du kan ikke sige på forhånd hvor hurtigt det går. Du kan komme med en worst case, ud fra om der er afhængigheder, men det kan meget nemt gå mange gange hurtigere. Det viser sig, at med n sideløbende processorer, der udfører instruktioner i rækkefølge, er “tendens” til, at der er en dybde på log2/n hvor n er antallet af instruktioner der udføres samtidigt, mens at forøgelsen er en faktor n – det giver en faktor n/log2(n) som middel forøgelse. Igen, er dette dog kun “typisk”, og ikke noget som kan bevises – tværtimod, kan findes matematiske algoritmer, hvor det ikke går hurtigt. Selvom processoren designes til at udføre instruktionerne i rækkefølge, så kan flere transistorer altså medføre væsentligt større hastighed. Der er ganske enkelt tendens til, at der ikke er så mange afhængigheder på “bit-niveau”, som man kan udregne på datalogisk niveau.
Og, sidst men ikke mindst, så kan vi analysere software – også sekventielt software – og organisere den, så det er muligt at øge parallelismen. Den slags “triks” kræver også transistorer.
Som du skriver, må der findes et “hul” der får transistor antallet ned, så vi kan bruge chippens transistorer til noget fornuftigt. Det gør det også. Det kan hjælpe, at flytte en del af opgaverne til softwaren – og det kan faktisk give langt bedre operativsystemer. I dag, så er det stort set altid programmørens opgave, at parallelisere opgaverne. Og operativsystemet er dårligt, til at sekventialisere de parallelle opgaver, og få dem ned på antallet af kerner som findes. Ved at lave denne software dårlig, så favoriseres processorer med flere kerner – gerne mange. Her er ikke så kritisk, at mapningen ned til en eller få kerner sker effektiv. Det er muligt at lave operativsystemerne således, at det er dem der står for at parallelisere opgaverne, og sekventialisere dem – i dag sker sekventialiseringen på den dårligste måde, ved hjælp af et interrupt der afbryder arbejdet, og sætter processoren i gang med en ny process. Det er det vi kan kalde den dummeste løsning. Når man gør det korrekt, så regner man ud hvordan at opgaverne skal udføres, for at de i gennemsnit, og samlet, bliver hurtigere først. Det opnås ikke, når du deler opgaverne. Det er faktisk en meget interessant – men også lidt svær opgave – at mappe mange parallelle processer effektiv ned i en eller få kerner. Udføres også parallelisering af sekventiel kode, så afhænger parallelismen af, i hvilken rækkefølge opgaverne løses, og du kan sætte flere ressourcer eller færre ressourcer af, på at øge eller reducere parallelisme. Ofte, så øges f.eks. parallelismen, hvis en løkke får lov til at køre nogle gange. Det kan også være muligt, at reducere dens indhold. Et godt operativsystem, får kode som den er i stand til at behandle fra programmerne, og derved kan øge og reducere parallelisme efter behov. Og, den er i stand til at behandle koden, således at den i nogle tilfælde reduceres. Har du en uendelig løkke, så vil den som regel ikke tage nogen tid, fordi den ikke har et output, og kan derfor udføres parallelt med dine andre opgaver. Den kan skubbes til at blive udført før, eller siden. Og en parallel opgave, uden output, behøver ikke at blive udført, så den fjernes. Du kan, hvis operativsystemet fungerer, ikke lave en uendelig løkke, eller pauser med løkker. Pauser med løkker reduceres bort online, mens paralleliseringen i OS’et kører. Alligevel, så udføres instruktionerne i rækkefølge.
Ovenstående metoder, hvor operativsystemet gøres mere intelligent, tror jeg er fremtiden. Dels, så behøver du ikke kode i så høj kvalitet, da operativsystemet gør koden hurtigere. Den kan også analysere den, og du kan få bevis for, hvor hurtig det kan udføres. Har du timing krav på, så tages hensyn til timing kravene, når processerne prioriteres og paralleliseres. Og, der kan på forhånd gives enten godkendelse, eller afslag, på realtidskrav som softwaren stiller. Det kræver, at operativsystemet kender hardwaren grundigt.
Altså – med andre ord – hvis du flytter en del af snasket med parallelisering fra hardwaren til softwaren, så bliver den mere kraftfuld. Softwaren reduceres ligefrem bort. Pauser, kan kun udføres, ved at gøre det korrekt – ikke med “for next” løkker, uden delays. Som regel, så vil der sættes krav til, at delays lægges på I/O’s, da instruktioner tidsmæssigt ingen tid tager, når de udsættes for analyse, reduktion, og paralleliseres således at rækkefølgen de udføres er ukendt, og kun funktionen 100% bevares. Står et delay i programmet, så vil den reelt sløve alt ned, og skulle lægges på samtlige I/O’s der udføres senere. Det er oftest upraktisk. Og, det er bedre at “anbringe” delays, ved at gøre det på selve I/O enheden, f.eks. sende en delay til skærmen, hvis det er en delay på skærm som ønskes. Et delay må helst ikke forekomme i selve softwaren.
Med mere intelligente operativsystemer, så vil processorens transistorer kunne bruges mere effektiv. Og, det vil være muligt at operativsystemerne bliver mere intelligente, og at hver generation vil kunne løse større reduktionsopgaver.
Leave a Reply