Vi har ikke kunne følge med Moors lov siden 2010

Det er ikke Moores lov, der halter. Den siger, at antallet af transistorer per chip fordobles ca. hver 18 måneder. Det sker stadig.

Det, der er slut, er Dennard scaling: En observation om, at strømforbruget per cm² er nogenlunde konstant, selv om antallet af transistorer per cm² fordobles. Det holdt indtil ca. 2005, men derefter er strømforbruget per transistor nogenlunde konstant, selv om man skrumper disse. Det skyldes bl.a., at det meste strømforbrug sker i interconnect og ikke i selve transistorerne.

Så en rimelig strategi inden 2005 var at skrumpe transistorerne og øge clockfrekvensen (som stiger kvadratisk med clockfrekvens). Men forøget clockfrekvens koster for meget i energi og køling, så man har i stedet sat flere kerner på en chip -- det koster kun lineært ekstra i energiforbrug, og hvis flere kerner kan dele f.eks. sekundær cache, lidt mindre end lineært. I mange tilfælde har man samtidig droslet ned for clockfrekvensen.

Umiddelbart lyder de 6GHz mestendels som et publicity stunt -- det ser godt ud på en pressemeddelelse, der ikke nævner et skyhøjt strømforbrug.

Æhhh... Vi har ikke kunne følge med Moors lov siden 2010... Det er ved at være noget tid siden...

Der er ingen grund til de høje klokfrekvenser. Præcist det samme - ækvivalent med høj klokfrekvens, og præcist samme antal indstruktioner per sekund, kan opnås ved at udføre flere indstruktioner i en cycle - også med afhængigheder. Og, det er tilmed muligt at øge hastigheden, hvis der ikke er afhængigheder mellem de to indstruktioner. Typisk vil man udføre flere indstruktioner i en enkelt cycle, og data forwardes mellem dem, hvis der er afhængigheder. Registerfilerne har flere ind/udgange, og der kan læses/skrives simultant. På grund af forwardningen af data mellem processorerne så opstår ikke læse/skrive hazard. Når man forwarder, så læses det fra forward køen, og derfor opstår ingen hazard. Ved skrivning sker det prioriteret, således kun den sidste ord skrives, hvis flere skriver til samme celle. De første der ignoreres, behøver man ikke at tænke på, da de læses fra forwardningen, hvis de bruges. Fordelen er, at man samtidigt bruger den gamle n-mos teknologi, hvor man precharger processorerne, og lader dem arbejde på skift. Dette gør, at de fortæller hvornår de er færdige med indstruktionerne. I modsætning til moderne CMOS processorer, så fortalte de gamle pre-chargede nmos processorer, hvornår de var færdig, og de var derfor mange gange hurtigere. Var ingen afhængigheder, så var de færdig prompte. Der var to udgange, en til 1 og en til 0, og afhængigt af hvilken der blev trukken lav, så var udgangen høj eller lav. Var der afhængigheder, to det længere tid inden af af dem blev trukken lav eller høj. Det betyder, at den hastighed som indstruktionerne udføres med nu ikke mere afhænger af klokfrekvensen. Klokfrekvensen justeres af, hvornår at data foreligger. Det er den tid, som det tager at udføre den aktuelle indstruktion, og de afhængigheder der er, der betyder hastigheden. Precharge tiden betyder ingenting, da den ikke indgår i den tid som beregningen tager. Der går så lang tid, inden den anvender den samme processor element igen, at en forlængst er precharged inden, og klar til en ny beregning. Derfor, er det forward tiden, som betyder hvor lang tid en operation tager, og den svarer typisk til delay på 1-2 inverters. Dette giver en hastighed der svarer til et tocifret gigahertz. Denne teknologi, sætter tilmed ingen krav til registerfilens hastighed. Og du kan umuligt aflæse udefra, at processoren ikke har en hastighed på et tocifret antal gigahertz. Selvom du angiver antallet af klokcycles med den høje hastighed, så vil de overholdes.

En af fordelene ved denne teknik, er at det ikke er samme ALU der laver beregningen, når der udføres to indstruktioner eller flere efter hinanden. De udfører indstruktionerne på skift. Og det betyder, at varmeafsæningen også sker på skift. Man kan forestille sig det sådan, at man folder fortolkerløkken ud i emuleringen af CPU'en. Tager du et program, og omsætter til en dataflow graf, så kan denne dataflow graf direkte omsættes til hardware. Dette fylder imidlertid meget. Laver du en fortolker, som fortolker noget kode, f.eks. en CPU's kode, så vil dette automatisk omsættes til en CPU. Der findes regler for, hvordan at dette gøres automatisk: CPU'er er ikke noget man sidder og designer. Det er et software program, en såkaldt fortolker, der står og kører. Og sætter du dens inderløkke til at udføre flere indstruktioner per klokcycle, f.eks. med en for-next, hvor der udføres flere indstruktioner, så vil den fordi der ikke er nogen klok udfolde denne løkke, således der genereres flere ALU'er, hvor indstruktionerne udføres på skift, og data forwardes mellem disse ALU'er - dette sker automatisk. Det eneste du skal, når du laver en hurtigere CPU, er at ændre hvor mange loops din for-next løkke tager.

Jeg er i gang med en hjemmeside, hvor jeg sandsynligvis vil gå metoden detaljeret igennem, og komme med nogle eksempler. For det virker som om, at det er noget man har "glemt" at undervise i i digital elektronik. Sammenhængen mellem hardware dataflow grafer (diagrammer) og software, er ekstremt vigtigt at forstå, og hvordan det fungerer, når man konverterer mellem dem, og hvordan at fortolkerkode bliver automatisk til CPU'er.

Så det giver ikke rigtigt mening om CPU'en har en intern klokfrekvens på 6 GHz eller ej, for der er ganske enkelt ingen måde, hvor vi kan undersøge om Intels CPU'er faktisk har det. Det er umuligt at tjekke udefra. Det er en ren påstand. Hvis man bruger den teknik som jeg beskriver, så vil den udefra altid se ud som om, at den har den hastighed som den er programmeret til at have, og denne bestemmes alene af den kombinatoriske delay imellem udfoldede CPU'er igennem forward køerne. Den kan komme ned på en delay der svarer til ca. to inverters.

Det bedste ved den metode som jeg beskriver er, at indstruktionerne samtidigt udføres parallelt, og hvis der ikke er afhængigheder, så bliver den tid, som en intern klokcycle tager mindre. Så det er meget simpel: Ingen ved et hak om hvad der sker inde i CPU'en, og man kan nemt få den til at syne af en nærmest vilkårlig høj klokfrekvens.

Vi har også teknikker, så vi kan ophæve klokkens strømforbrug, ved hjælp af interne induktioner. Men der er alligevel et tab. Vi kan anvende teknikker der svarer til CCD'er, hvor at ladningerne flyttes, og der derfor er mindre energiforbrug. Når du flytter en negativ ladning, så svarer det til at der er en automatisk pull-up på indgangen, og at den trækker udgangen lav, uden der bruges nogen energi. For når elektronerne fjernes, så svarer det til at trække høj, og når de tilføres, svarer det til at trække lavt. Dette kan ske næsten uden energiforbrug, hvis klokkens kapaciteter ophæves med induktioner. Dog er nødvendigt at genopfriske data indimellem.