Computerprestaties en abstractielagen

Een abstractie laat zien wat een onderdeel doet en verbergt de details van hoe het werkt. Een browser kan het besturingssysteem vragen een bestand te lezen zonder de schakelingen van het opslagapparaat aan te sturen. Dankzij vastgelegde interfaces kunnen mensen onderdelen van een systeem ontwerpen, testen en vervangen zonder elke laag tegelijk opnieuw te bouwen.

De lagen en hun taken

Een gebruikelijke volgorde, van de taak van de gebruiker tot de fysieke componenten, is:

1. Applicatiesoftware voert taken uit zoals een spreadsheet bewerken of op internet surfen.
2. Systeemsoftware levert gedeelde diensten en vertaalt programma's. Hieronder vallen besturingssystemen, compilers, assemblers, linkers en bibliotheken.
3. De instructiesetarchitectuur (ISA) definieert de machine-instructies en ander gedrag dat zichtbaar is voor software op laag niveau.
4. De microarchitectuur, of organisatie, implementeert die ISA met een datapad, besturingseenheid, pipelines en caches.
5. Digitale logica bouwt bewerkingen en opslag op uit poorten, optellers, multiplexers en registers.
6. Schakelingen verbinden elektronische componenten om die logica te realiseren.
7. Componenten, vooral transistors, zorgen voor het fysieke schakelgedrag.

Deze grenzen zijn nuttige manieren om naar één machine te kijken. Verschillende diagrammen kunnen aangrenzende lagen samenvoegen. Een besturingssysteem is software: de CPU voert de instructies ervan uit, waaronder instructies met bijzondere bevoegdheden die helpen om bronnen veilig te beheren.

Volg één optelling

Bekijk de C-instructie total = price + tax;. Een compiler kiest waar waarden worden bewaard en welke instructies de optelling uitvoeren. De compiler kan een optelinstructie kiezen zonder een opteller te ontwerpen. Een microarchitect koppelt die instructie aan uitvoeringshardware. Een logicaontwerper bouwt de opteller uit poorten; een schakelingontwerper houdt zich bezig met de elektrische details achter die poorten. Ieder gebruikt een eenvoudigere interface naar het onderliggende niveau.

De fysieke computer heeft vijf klassieke onderdelen: invoer, uitvoer, geheugen, datapad en besturingseenheid. Het datapad voert bewerkingen uit op gegevens. De besturingseenheid stuurt bewerkingen aan en coördineert geheugen, invoer en uitvoer. Samen vormen datapad en besturingseenheid de processor, of CPU.

Een transistor werkt als een elektrisch aangestuurde schakelaar. Een geïntegreerde schakeling, of chip, verenigt veel transistors op één stuk silicium. Die schakelaars ondersteunen logica; de logica ondersteunt instructies; instructies ondersteunen software.

Meer transistors en verschillende snelheden

De wet van Moore begon met een observatie van Gordon Moore uit 1965 en werd in 1975 herzien tot een trend waarbij het aantal transistors ongeveer elke twee jaar verdubbelde. Tien van zulke verdubbelingen vermenigvuldigen een aantal in ongeveer 20 jaar met $2^{10}=1024$. Dit is een productietrend, geen natuurkundige garantie; het tempo is vertraagd.

Als een onderdeel aan een interface voldoet, blijft het door die interface beloofde gedrag behouden. Dat legt de prestaties, het energieverbruik of de kosten niet vast. Twee processors kunnen dezelfde optelinstructie correct implementeren en toch verschillende schakelingen, caches en klokfrequenties gebruiken. De applicatie krijgt hetzelfde berekende resultaat, maar wacht er niet even lang op.

Een processor voert machinetaal uit: instructies die als bits zijn gecodeerd. Code in een hogere programmeertaal beschrijft een berekening met variabelen, expressies, lussen en functies. Vertaling overbrugt die twee weergaven en breidt een korte instructie vaak uit tot meerdere machine-instructies.

Het pad van een gecompileerd programma

Voor een C-programma zijn de belangrijkste stappen:

Een objectbestand kan machinecode bevatten zonder al een volledig uitvoerbaar programma te zijn. Voor een aanroep van een functie die in een ander bestand is gedefinieerd, moet de linker bijvoorbeeld die verwijzing oplossen. De loader maakt deel uit van de uitvoeringsondersteuning van het besturingssysteem en is geen extra vertaler van broncode.

Volg één C-instructie

Stel dat price in register x6 staat, tax in x7 en de compiler total in x5 plaatst. Dan kan:

total = price + tax;

worden omgezet in deze RISC-V-instructie:

add x5, x6, x7

De bestemming staat vooraan in de assembleertekst. De instructie telt de waarden in x6 en x7 op en schrijft het resultaat naar x5. De 32-bits R-typecodering plaatst de velden in een andere volgorde:

Door de velden samen te voegen krijg je 0000000 00111 00110 000 00101 0110011, of 0x007302B3. De spaties maken de velden leesbaar; ze worden niet als deel van de instructie opgeslagen.

Eén instructie in de broncode hoeft niet één machine-instructie te betekenen. Zelfs als alle operanden in registers staan, vereist f = (g + h) - (i + j); twee optellingen en een aftrekking. Operanden uit het geheugen laden voegt instructies toe. Het aantal uitgevoerde instructies hangt dus af van de vertaling en de ISA, niet alleen van het aantal broncoderegels.

Andere routes naar machinecode

Een programma in een hogere programmeertaal kan vaak opnieuw worden gecompileerd voor een andere ISA. Het bestaande uitvoerbare bestand is gebonden aan zijn ISA en de conventies van het besturingssysteem. Een uitvoerbaar x86-64-bestand moet opnieuw worden gecompileerd, geëmuleerd of binair vertaald om te draaien op een Arm- of RISC-V-machine die het niet rechtstreeks kan uitvoeren.

Bytecode is een tussenformaat voor instructies van een uitvoeringsomgeving voor een programmeertaal. CPython compileert Python-broncode naar bytecode en interpreteert die met een interpreter. Virtuele Java-machines gebruiken vaak just-in-timecompilatie (JIT-compilatie) om veelgebruikte bytecode tijdens de uitvoering van het programma om te zetten in machinecode. In beide gevallen voert de fysieke CPU uiteindelijk machine-instructies uit.

Assembleertaal blijft tekst, ook als een regel sterk op een echte instructie lijkt. Een pseudo-instructie is een hulpmiddel dat de assembler accepteert: RISC-V mv x5, x6 wordt addi x5, x6, 0. Nauwkeurige controle over instructies kan nuttig zijn in code van besturingssystemen en kritieke lussen, maar je levert daarmee een deel van de overdraagbaarheid en de vrijheid van de compiler bij code in een hogere programmeertaal in.

De instructiesetarchitectuur (ISA) is het contract tussen hardware en software op het laagste niveau. Ze vertelt een programmeur in machinetaal welke bewerkingen bestaan en wat die betekenen. Het interne ontwerp van een processor kan veranderen terwijl dat contract stabiel blijft.

Wat het contract vastlegt

Een ISA definieert instructies en hun binaire codering, voor de programmeur zichtbare registers, adresseringsgedrag, ondersteunde gegevenstypen en de architecturale mechanismen voor toegang tot invoer en uitvoer. Een compiler richt zich op deze eigenschappen wanneer die een berekening omzet in instructies.

Een implementatie is een fysiek ontwerp dat aan de ISA voldoet. De microarchitectuur beschrijft interne keuzes zoals uitvoeringseenheden, pipelinestappen, cachegroottes en sprongvoorspelling. Die keuzes hebben veel invloed op de uitvoeringstijd.

Het onderscheid gaat over het beloofde gedrag. Een programma moet het vastgelegde resultaat van de vermenigvuldiging krijgen. Het hoeft meestal niet te weten hoe de vermenigvuldiger is gebouwd om dat resultaat te krijgen.

Waarom een ISA alleen niet genoeg is voor binaire compatibiliteit

De binaire applicatie-interface (ABI) voegt de interface van het besturingssysteem en binaire conventies toe aan de ISA op gebruikersniveau. De ABI legt aanroepconventies vast, zoals argumentregisters, samen met de indeling van gegevens en conventies voor systeemaanroepen. Twee machines kunnen dezelfde instructiecoderingen uitvoeren en toch verschillen in hoe een functie een argument ontvangt.

Voor binaire compatibiliteit moeten de ISA-eigenschappen en ABI van het programma worden ondersteund. Zelfs binnen de x86-familie, die begon met de Intel 8086 uit 1978, zijn ondersteuning door het besturingssysteem en uitvoeringsmodi van belang. Achterwaartse compatibiliteit heeft veel oudere programma's behouden terwijl processorimplementaties zijn veranderd, maar een gedeelde familienaam garandeert niet dat elk historisch uitvoerbaar bestand in elke omgeving draait.

Eén architectuur, veel implementaties

Intel en AMD implementeren x86-64 met verschillende interne ontwerpen. Arm en RISC-V ondersteunen eveneens implementaties met sterk verschillende vermogensbudgetten en prestaties. RISC-V ontstond in 2010 aan de University of California, Berkeley en is een open ISA zonder licentievergoedingen. De basisinstructiesets voor gehele getallen omvatten RV32I en RV64I; standaarduitbreidingen omvatten M voor vermenigvuldiging en deling van gehele getallen en F en D voor drijvendekommabewerkingen.

Een programma dat een optionele uitbreiding gebruikt, heeft een implementatie nodig die deze ondersteunt. Een gedeelde basis betekent niet dat elke uitbreiding overal beschikbaar is. Het RISC-V-voorbeeld met optelling illustreert dezelfde grens tussen hardware en software als bij Arm en x86, al verschillen hun instructies en coderingen.

Uitgebreide instructiesets en uitvoeringstijd

Een ISA kan meer werk in één instructie uitdrukken en zo het aantal instructies verminderen. Die instructie kan ook meer cycli kosten of een langere cyclus vereisen. De relevante berekening is het volledige product:

Een uitgebreidere instructieset volstaat niet om te bepalen welke machine sneller is. Een gedeelde ISA betekent evenmin dat de snelheid gelijk is: compatibele processors kunnen verschillende klokfrequenties, caches en uitvoeringseenheden gebruiken om dezelfde vereiste resultaten te leveren.

Iemand die op een bestandsconversie wacht, wil een korte responstijd. Een dienst die veel conversies verwerkt, heeft ook een hoge doorvoer nodig. Deze maten beantwoorden verschillende vragen, ook als ze dezelfde computer beschrijven.

Kies de grootheid die bij de taak past

De responstijd, ook wel uitvoeringstijd of latentie genoemd, loopt van het begin van de taak tot de voltooiing ervan. Daaronder vallen rekentijd, toegang tot geheugen en opslag, invoer en uitvoer en relevante activiteit van het besturingssysteem. Als de taak na het indienen in een wachtrij staat, telt die wachttijd mee voor de responstijd van de gebruiker.

Doorvoer is voltooid werk per tijdseenheid. De eenheid kan bijvoorbeeld verzoeken per seconde of taken per uur zijn. Een machine kan veel taken per uur voltooien terwijl elke afzonderlijke taak toch lang duurt.

Extra processors kunnen de doorvoer verhogen door onafhankelijke taken tegelijk uit te voeren. Ze hoeven de berekening van een taak zelf niet te verkorten, al kunnen ze de wachttijd op een vrije processor verminderen. Een snellere processor helpt vaak bij beide maten.

Vergelijk prestaties in de juiste richting

Definieer voor dezelfde taak:

Als A 10 s nodig heeft en B 15 s, is de prestatie van A ten opzichte van B:

A is 1,5 keer zo snel. De prestatie van B is twee derde van die van A. Zet de grotere uitvoeringstijd boven de kleinere als je aangeeft hoeveel keer zo snel de snellere machine is.

Bij een verbetering is de versnellingsfactor de oude tijd gedeeld door de nieuwe tijd. Een bouwproces dat van 60 s naar 48 s gaat, heeft als versnellingsfactor:

De tijdsvermindering is:

De prestatie steeg met 25%, terwijl de tijd met 20% daalde. Deze percentages gebruiken verschillende noemers. Als je “20% sneller” zegt, kan onduidelijk blijven welke grootheid veranderde; de verhouding en de gemeten tijden maken de bewering helder.

Gelijke doorvoer kan verschillende wachttijden verbergen

Een dienst die 1.200 verzoeken per minuut voltooit, levert 20 verzoeken per seconde. Die snelheid kan ontstaan door elke 50 ms één verzoek te verwerken, waarbij elk verzoek 50 ms duurt. Ze kan ook ontstaan door tien verzoeken parallel te verwerken die elk 500 ms duren: tien voltooide verzoeken per halve seconde geeft opnieuw 20 per seconde.

De tweede inrichting heeft dezelfde doorvoer maar tien keer zoveel verwerkingstijd per verzoek. Een doorvoerresultaat alleen kan niet vaststellen welke latentie een gebruiker ervaart. Vergelijk hetzelfde voltooide werk, vermeld het tijdsinterval en behoud de eenheden wanneer je omrekent tussen minuten en seconden.

Een stopwatch meet alles tussen begin en einde. De CPU-prestatieformule meet processorwerk. Door die twee manieren van kijken te onderscheiden, voorkom je dat je een processorupgrade winst toeschrijft voor wachttijd die deze niet kan wegnemen.

Verstreken tijd en processortijd

Verstreken tijd, of wandkloktijd, omvat rekentijd, wachten op bestanden of het netwerk en perioden waarin andere processen draaien. CPU-tijd registreert processortijd die aan de taak wordt toegerekend. CPU-gebruikerstijd is de tijd voor het uitvoeren van de programmacode; CPU-systeemtijd is de tijd voor het uitvoeren van code van het besturingssysteem namens het programma.

Stel dat de Unix-opdracht time “real 2.50 s, user 1.80 s, sys 0.20 s.” rapporteert. Het programma gebruikte:

aan CPU-tijd. In dit tijdmetingsvoorbeeld met één thread staat de resterende 0,50 s voor tijd die niet als CPU-uitvoering is toegerekend, zoals wachttijd of tijd waarin een ander proces werd ingepland. Als een processorverbetering het CPU-deel halveert terwijl die wachttijd gelijk blijft, wordt de verstreken tijd:

Als je de volledige 2,50 s zou halveren, zou je ten onrechte ook het wachten versnellen. Bij CPU-prestaties ligt de nadruk vaak op gebruikerstijd; systeemprestaties worden beoordeeld met de verstreken tijd bij een gecontroleerde systeembelasting.

Bij een parallel programma wordt de CPU-tijd opgeteld over de threads en kernen. Vier kernen die het grootste deel van één seconde werken, kunnen 3,6 s gebruikerstijd opleveren tijdens 1,0 s verstreken tijd. In dat geval meet je de wachttijd niet door de opgetelde CPU-tijd van de verstreken tijd af te trekken.

Klokfrequentie is het omgekeerde van de periode

Een klok geeft synchrone hardware een tijdritme. De klokperiode is het aantal seconden per cyclus; de klokfrequentie is het aantal cycli per seconde:

Bij 4 GHz is de frequentie vier miljard cycli per seconde. Eén cyclus duurt:

Bij 2,5 GHz is de periode 400 ps. Andersom geeft 312,5 ps per cyclus:

Voorvoegsels voor tijd en frequentie gebruiken machten van tien. Binaire geheugenvoorvoegsels gebruiken machten van twee. Aanduidingen zoals “GB” worden soms losjes gebruikt voor binaire grootheden, dus controleer de betekenis voordat je een grootte omrekent.

Interpreteer een meting als één uitvoering

De opgegeven frequentie van een processor is geen registratie van elk moment van de uitvoering. Tijdelijke frequentieverhoging, energiebeheer en thermische snelheidsbegrenzing veranderen de frequentie. Ook cache-inhoud en achtergrondactiviteit veranderen de gemeten tijd. Door een meting te herhalen en een typische waarde te rapporteren, zoals de mediaan, kun je een stabiel resultaat onderscheiden van een uitzonderlijk gunstige uitvoering. Gebruik tijd- en frequentiemetingen uit hetzelfde uitvoeringsinterval wanneer je die aan aantallen cycli koppelt.

Een klokcyclus is een eenheid van processortijd, geen instructie. Sommige instructies hebben veel cycli nodig en door overlappende uitvoering kunnen meerdere instructies per cyclus worden voltooid. Begin met het totale aantal cycli dat het hele programma nodig heeft.

Deel cycli door cycli per seconde

Als een programma een bekend aantal cycli nodig heeft, is de CPU-tijd:

Voor zes miljard cycli bij 3 GHz:

De eenheden verklaren de deling: cycli gedeeld door cycli per seconde geeft seconden. Cycli vermenigvuldigen met frequentie zou cycli in het kwadraat per seconde opleveren, geen tijdsduur. Vermenigvuldigen met de periode werkt wel, omdat de eenheid daarvan seconden per cyclus is.

Met dezelfde formule kun je een andere onbekende bepalen. Vermenigvuldig tijd met frequentie om het aantal cycli terug te vinden; deel cycli door de doeltijd om de benodigde frequentie te vinden. Gebruik Hz voor de frequentie als de tijd in seconden is gegeven, of streep overeenkomstige factoren van een miljard expliciet tegen elkaar weg.

Als een hogere klokfrequentie meer cycli vereist

Processor A voert een programma uit in 10 s bij 3 GHz. Het cyclusbudget is:

Een voorgesteld ontwerp B verhoogt dat aantal cycli met 20%. B moet daarom uitvoeren:

Om in 9 s klaar te zijn, heeft B nodig:

De verhouding tussen de klokfrequenties is vier derde, ongeveer 1,33. De werkelijke versnellingsfactor is slechts tien negende, ongeveer 1,11, omdat B meer kloktikken nodig heeft om het werk te voltooien. Als je ervan uitgaat dat het oude aantal cycli gelijk blijft, voorspel je een klokfrequentie die te laag is om het doel te halen.

Vergelijk een afweging zonder een programmaomvang te kiezen

Stel dat een ontwerp het oude aantal cycli vermenigvuldigt met een factor $a$ en de oude klokfrequentie met een factor $b$. Dan geldt:

Het ontwerp is sneller als de groeifactor van het aantal cycli kleiner is dan de groeifactor van de frequentie. Als beide met dezelfde factor groeien, blijft de CPU-tijd gelijk. Deze verhouding is nuttig als een ontwerpvoorstel procentuele veranderingen vermeldt maar geen absoluut aantal cycli geeft.

Waarom de periode een fysieke grens heeft

Tussen registers gaan signalen door combinatorische logica en moeten ze stabiel worden voordat hun resultaten worden vastgelegd. Het traagste vereiste pad is het kritieke pad. De schakelingstechnologie en de hoeveelheid werk die aan een stap is toegewezen, begrenzen hoe kort een veilige klokperiode kan zijn.

Een ontwerper kan werk over kortere pipelinestappen verdelen om een hogere klokfrequentie mogelijk te maken, maar die reorganisatie kan ook het aantal cycli veranderen. Meer GHz is dus een uitspraak over de frequentie van kloktikken. Om een prestatieverbetering vast te stellen, combineer je die met het aantal cycli dat het programma onder dat ontwerp daadwerkelijk nodig heeft.

Cycli per instructie (CPI) is het totale aantal CPU-cycli van een programma gedeeld door het aantal uitgevoerde instructies. Het is een gemiddelde over één uitvoering en kan dus een gebroken getal zijn. De CPI hangt af van welke instructies worden uitgevoerd en hoe die met de machine samenwerken.

Tel de cycli op voordat je het gemiddelde neemt

Voor instructieklassen met aantallen $C_i$ en CPI's per klasse $c_i$ geldt:

Je kunt ook de CPI van elke klasse vermenigvuldigen met het aandeel van die klasse in het aantal instructies en de bijdragen optellen. De aandelen moeten uitgevoerde instructies beschrijven, geen broncoderegels of aantallen instructietypen.

Stel dat ALU-instructies 1 cyclus kosten, laad- en opslaginstructies 4 en voorwaardelijke sprongen 2. Een mix van 50%, 30% en 20% geeft:

Voor vijf miljard instructies bij 3 GHz is het totaal 10,5 miljard cycli en de CPU-tijd 3,5 s. Het ongewogen gemiddelde van de drie kosten per klasse, ongeveer 2,33, is onjuist: de klassen komen niet even vaak voor.

Meer instructies kunnen toch minder cycli betekenen

Twee compilerversies gebruiken dezelfde kosten per klasse:

Versie 1 voert 800 miljoen instructies uit. De bijdragen aan het aantal cycli zijn 400, 1.200 en 200 miljoen, in totaal 1.800 miljoen. De CPI is:

Versie 2 voert 850 miljoen instructies uit. De bijdragen zijn 600, 600 en 200 miljoen, in totaal 1.400 miljoen. De CPI is:

Bij 3 GHz zijn de tijden 0,60 s en ongeveer 0,467 s. Versie 2 is ongeveer 1,29 keer zo snel, hoewel die 50 miljoen instructies meer uitvoert. Veel dure geheugeninstructies vervangen door meer goedkope ALU-instructies kan die afweging lonend maken.

CPI hoort bij een werklast op een machine

Geheugenwachtcycli, cachemissers, spronggedrag en compilerkeuzes veranderen de effectieve CPI. Eén “processor-CPI” kan niet elk programma beschrijven. Hardwarematige prestatietellers of een simulator kunnen de totale aantallen instructies en cycli meten voor de werklast die wordt geanalyseerd.

Instructies per cyclus (IPC) gebruikt dezelfde totalen in omgekeerde volgorde:

Een IPC van 2,5 geeft een CPI van 0,4. Meerdere instructies kunnen overlappen in een processor die meerdere instructies per cyclus uitgeeft en voltooit. Een gemiddelde onder één betekent niet dat een afzonderlijke instructie haar volledige traject in een fractie van een kloktik aflegt.

De CPU-prestatieformule brengt de drie tijdfactoren samen:

Hier telt $I$ de uitgevoerde instructies en is $f$ de klokfrequentie die tijdens de uitvoering geldt. Instructies maal cycli per instructie geeft cycli. Delen door cycli per seconde geeft vervolgens seconden.

Bereken een tijd en bepaal een onbekende

Een programma voert twee miljard instructies uit bij een CPI van 1,5 op een processor van 2,5 GHz. Bepaal eerst het totale aantal cycli en zet dat daarna om in tijd:

Om de CPI uit de gemeten tijd af te leiden, herleid je dezelfde formule:

Voor 1,6 miljard instructies in 0,8 s bij 3,2 GHz zijn er 2,56 miljard cycli. Delen door 1,6 miljard instructies geeft een CPI van 1,6.

Vergelijk volledige producten

Twee processors voeren hetzelfde gecompileerde programma uit met hetzelfde aantal instructies. A heeft 4 GHz en een CPI van 1,8; B heeft 2,5 GHz en een CPI van 1,0. Hun tijd per instructie is:

B is 1,125 keer zo snel. De lagere CPI van B compenseert de lagere klokfrequentie ruimschoots. Het aantal instructies valt hier weg omdat het gelijk is; dat zou niet zo zijn als de twee programma's verschillende instructiereeksen volgden.

Een compileroptie die het aantal instructies met 10% vermindert maar de CPI met 15% verhoogt, bij dezelfde frequentie, verandert de tijd met een factor:

De tijd stijgt met 3,5%. Als je alleen naar de vermindering van het aantal instructies kijkt, wijst die in de verkeerde richting.

Verbind ontwerpkeuzes met de factoren

Deze verbanden zijn nuttig voor analyse, maar zijn geen onafhankelijke regelknoppen die je altijd zonder gevolgen kunt aanpassen. Een cache vermindert geheugenwachtcycli en verlaagt daarmee de effectieve CPI. Pipelining laat opeenvolgende instructies overlappen en kan de effectieve CPI verlagen of een kortere klokperiode mogelijk maken. Zulke veranderingen kunnen andere kosten meebrengen die in de gemeten totalen zichtbaar worden.

Houd het meetinterval gelijk

Meet CPU-tijd, aantal uitgevoerde instructies, cycli en frequentie voor hetzelfde werk. Tellers of simulatie leveren aantallen instructies en cycli. De opgegeven GHz-waarde van een product is geen registratie van de frequentie tijdens een uitvoering waarbij die wordt verhoogd of verlaagd. Als de frequentie varieert, is het bijbehorende gemiddelde het totale aantal getelde cycli gedeeld door de CPU-tijd voor dat interval.

De formule voorspelt de CPU-uitvoeringstijd. Wachten op opslag of het netwerk hoort bij de verstreken tijd en moet afzonderlijk worden meegenomen als de gebruiker die tijd nodig heeft.

Een nuttige bewering over prestaties gaat over werk dat voor de gebruiker van belang is. Een benchmark voert een gekozen werklast uit om prestaties te meten. Een benchmarkverzameling neemt meerdere werklasten als steekproef wanneer één applicatie niet de volledige behoefte kan vertegenwoordigen.

Lees welk soort SPEC-resultaat je hebt

SPEC CPU 2026, uitgebracht in mei 2026, volgt op SPEC CPU 2017. De verzamelingen belasten processors, geheugensystemen en compilers. SPECspeed meet de voltooiingstijd van één exemplaar van een programma; dat exemplaar kan zelf meerdere threads gebruiken. SPECrate meet de doorvoer met meerdere exemplaren. De verzamelingen voor gehele getallen en voor drijvendekommagetallen dienen verschillende soorten werklasten en het product ondersteunt ook energiemaatstaven.

Een snelheidsverhouding voor één programma vergelijkt de referentietijd met de gemeten tijd:

Een referentietijd van 3.000 s en een gemeten tijd van 250 s geven 12. Hoger is beter. Een doorvoerverhouding omvat het aantal exemplaren dat in het gemeten interval is voltooid. Vergelijk gelijksoortige maatstaven en dezelfde versie van de verzameling; een snelheidsscore en een doorvoerscore beantwoorden verschillende vragen.

Vat verhoudingen samen met een meetkundig gemiddelde

Voor positieve verhoudingen gebruikt de verzameling:

De verhoudingen 2, 8 en 4 geven een product van 64 en een derdemachtswortel van 4. Hun rekenkundig gemiddelde is ongeveer 4,67, een ander resultaat.

De vergelijking van meetkundige gemiddelden hangt niet af van de referentiemachine die de verhoudingen bepaalt. Stel dat X 10 s en 40 s nodig heeft voor twee programma's, terwijl Y 20 s en 25 s nodig heeft. Referentietijden van 100 s voor beide geven verhoudingen van 10 en 2,5 voor X en 5 en 4 voor Y. De meetkundige gemiddelden zijn 5 en ongeveer 4,47, dus X ligt ongeveer een factor 1,12 voor.

Verander de referentietijden naar 50 s en 200 s: X krijgt verhoudingen van 5 en 5, Y krijgt 2,5 en 8. Hun meetkundige gemiddelden blijven 5 en ongeveer 4,47. De rekenkundige gemiddelden veranderen daarentegen van 6,25 tegenover 4,5 naar 5 tegenover 5,25, waardoor de rangorde omkeert. Normalisatie op basis van de referentie mag niet bepalen welke machine sneller lijkt.

Waarom MIPS langzamere code kan belonen

MIPS, miljoen instructies per seconde, is:

Instructies verrichten verschillende hoeveelheden nuttig werk in verschillende ISA's. Zelfs op één machine verandert MIPS met het programma en kan een hogere instructiesnelheid samengaan met een langere uitvoeringstijd.

Stel dat bij 3 GHz ALU-instructies, laad- en opslaginstructies en voorwaardelijke sprongen 1, 4 en 2 cycli kosten. Code Q voert er 400, 300 en 100 miljoen van uit: 800 miljoen instructies, 1.800 miljoen cycli, 0,60 s, ongeveer 1.333 MIPS. Code P voert er 1.500, 100 en 100 miljoen uit: 1.700 miljoen instructies, 2.100 miljoen cycli, 0,70 s, ongeveer 2.429 MIPS. P voltooit instructies sneller maar rondt de taak later af.

Piekverwerkingssnelheden beschrijven de ideale hardwarecapaciteit. Werkelijke werklasten kunnen veel minder bereiken door afhankelijkheden, geheugenwachttijden en andere grenzen. Gebruik de werkelijke taaktijd om de prestaties voor die taak te beoordelen; frequentie, MIPS en piekverwerkingssnelheden verklaren er slechts bepaalde delen van.

De wet van Amdahl begint met het verdelen van de oorspronkelijke uitvoeringstijd in een beïnvloed deel en een onbeïnvloed deel. Versnel alleen de beïnvloede tijd en tel de delen daarna weer bij elkaar op. Zo voorkom je dat je een lokale verbetering toepast op werk dat niet kan veranderen.

Bouw de nieuwe tijd op uit oude tijden

Als het beïnvloede deel $s$ keer zo snel wordt:

Neem $f$ als de beïnvloede fractie van de oorspronkelijke uitvoeringstijd. Delen door de oorspronkelijke tijd geeft de vorm met de versnellingsfactor:

Een programma van 120 s besteedt 90 s aan drijvendekommabewerkingen en 30 s aan ander werk. De beïnvloede fractie is dus 0,75. Door drijvendekommabewerkingen drie keer zo snel te maken, daalt de tijd daarvoor naar 30 s:

De drijvendekommabewerkingen worden een factor drie sneller; het volledige programma wordt een factor twee sneller. De onveranderde 30 s verklaart het verschil.

Reken terug vanuit een doel

Om dezelfde taak in 40 s te voltooien, heeft het onveranderde werk nog steeds 30 s nodig. Voor het deel met drijvendekommabewerkingen dat oorspronkelijk 90 s duurde, blijft slechts 10 s over. Daarom geldt:

Een doel van 30 s zou geen tijd overlaten voor dat werk. Geen eindige versnelling zorgt ervoor dat een positieve hoeveelheid beïnvloed werk precies nul tijd kost. Als de lokale versnellingsfactor onbegrensd groeit, nadert de totale versnellingsfactor:

Hier is de grens 4, die van onderaf wordt benaderd. Bij een onbeïnvloede fractie van de helft is de grens 2. Als al het werk wordt beïnvloed, is er geen onveranderde positieve tijd die zo'n eindige bovengrens oplegt.

Optimaliseer waar de tijd naartoe gaat

Het principe maak het veelvoorkomende geval snel betekent dat je vaststelt waaraan de uitvoeringstijd werkelijk wordt besteed. Prestatieprofilering meet die verdeling. Een deel dat 60% van de tijd kost twee keer zo snel maken, geeft:

Een tienvoudige verbetering van een deel van 10% geeft slechts:

Een grote lokale factor kan minder opleveren dan een bescheiden verbetering die op een groter deel van de taak wordt toegepast.

De beïnvloede fractie moet een tijdsfractie zijn. Als laad- en opslaginstructies 30% van de instructies vormen maar 60% van de cycli kosten, is hun tijdsfractie bij een vaste klokfrequentie 0,60. Als je instructies even zwaar telt, mis je hun hogere kosten.

Pas dezelfde verdeling toe op wachten

Voor een taak met 2,00 s CPU-werk en 0,50 s vaste wachttijd voor bestanden geeft een verdubbeling van de CPU-snelheid in totaal 1,50 s. De versnellingsfactor is ongeveer 1,67. Hetzelfde tijdbudget werkt voor verbeteringen van hardware, software en invoer en uitvoer: bepaal precies welke oorspronkelijke tijd verandert voordat je de factor toepast.

Meer kernen verkorten een taak alleen als werk tegelijk kan worden uitgevoerd. Verdeel de oorspronkelijke tijd van een vaste taak op één kern in een sequentieel en een parallel deel en bekijk vervolgens wat extra kernen kunnen veranderen.

De wet van Amdahl voor een taak met vaste omvang

Neem $p$ als de paralleliseerbare fractie van de oorspronkelijke tijd op één kern. Bij een perfecte verdeling over $N$ kernen en zonder overhead geldt:

Bij een paralleliseerbare fractie van 0,95 is de sequentiële fractie 0,05. Acht kernen geven:

Bij 100 kernen is de versnellingsfactor ongeveer 16,8; bij 1.000 kernen ongeveer 19,6. De sequentiële 5% houdt de versnellingsfactor bij vaste omvang onder 20, hoeveel kernen je ook toevoegt.

Parallelle efficiëntie is de versnellingsfactor gedeeld door het aantal kernen. De efficiëntie bij acht kernen is ongeveer 0,74, of 74%. Bij 100 kernen is die ongeveer 17%. Een grotere versnellingsfactor kan samengaan met lagere efficiëntie, omdat elke extra kern minder bijdraagt aan de vaste taak.

Waarom gemeten winst kleiner kan zijn

Het ideale model geeft het parallelle werk gelijke delen en kent geen coördinatiekosten. Werkelijke programma's communiceren en synchroniseren en sommige kernen krijgen meer werk dan andere.

Bij 100 gelijke eenheden onafhankelijk werk op vier identieke kernen geeft een evenwichtige verdeling elke kern 25 eenheden. Als één kern 40 eenheden krijgt terwijl de rest eerder klaar is, moet de voltooiing wachten op die drukste kern. De versnellingsfactor is 100 gedeeld door 40, ofwel 2,5, zelfs voordat communicatiekosten worden toegevoegd. De eerdere eindtijden van de andere kernen optellen zou niet de voltooiingstijd geven: het laatste vereiste resultaat bepaalt die tijd.

Een programma met één thread heeft geen paralleliseerbare fractie om te verdelen. Meer kernen kunnen nog steeds andere programma's draaien en de systeemdoorvoer verbeteren, maar ze verdelen de instructiestroom van dat programma niet automatisch.

Vast en groeiend werk stellen verschillende vragen

Sterke schaling houdt de totale probleemomvang vast en vraagt hoeveel sneller meer processors het probleem kunnen afhandelen. Zwakke schaling laat het totale werk evenredig met het aantal processors groeien, zodat het werk per processor ongeveer constant blijft. Een grotere simulatie kan een fijner raster gebruiken en tegelijk ongeveer dezelfde werklast per processor behouden.

De wet van Gustafson beschrijft geschaald werk wanneer de sequentiële tijd gelijk blijft terwijl het parallelle werk groeit. De sequentiële fractie $s$ wordt gemeten tijdens de parallelle uitvoering, anders dan de oorspronkelijke fractie op één kern bij Amdahl:

Bij een gemeten sequentiële fractie van 0,05 op 100 kernen is de geschaalde versnellingsfactor 95,05. Dit spreekt Amdahls grens van 20 voor een vaste taak met een oorspronkelijke sequentiële fractie van 5% niet tegen. De taakomvang en de meetbasis van de fractie verschillen.

Parallelle software moet onafhankelijk werk beschikbaar maken, evenwichtig verdelen en de resultaten coördineren. Meer hardware biedt capaciteit; de structuur van het programma bepaalt hoeveel van die capaciteit de voltooiingstijd verkort.

CMOS-processors verbruiken energie wanneer signalen schakelen en ook door lekstroom zolang ze onder spanning staan. Dynamische energie hangt samen met schakelen; statisch vermogen wordt ook opgenomen zonder nuttige schakelactiviteit. Hun onderlinge aandelen hangen af van de chip en de werklast.

Spanning heeft een kwadratisch effect

De energie die bij een overgang hoort, schaalt met de capaciteit en het kwadraat van de voedingsspanning. Een gebruikelijke uitdrukking gebruikt de helft van de capaciteit maal de spanning in het kwadraat; een volledige laad- en ontlaadpuls schaalt met de capaciteit maal de spanning in het kwadraat. Gebruik voor het gemiddelde dynamische vermogen:

Hier is $C$ de capacitieve belasting, $V$ de voedingsspanning, $f$ de klokfrequentie en beschrijft $\alpha$ de schakelactiviteit volgens de gekozen telconventie. Sommige conventies nemen een factor een half op in de activiteitsfactor. Verhoudingen zijn eenvoudig te berekenen als je dezelfde activiteitsconventie blijft gebruiken.

Bij ongewijzigde capaciteit en activiteit geeft een verlaging van zowel spanning als frequentie met 20%:

Het nieuwe dynamische vermogen is 51,2% van het oorspronkelijke. Alleen de spanning met 10% verlagen geeft een factor 0,81, een vermindering van 19% van het dynamische vermogen en de energie per overgang.

Een lagere spanning vertraagt ook het schakelen van transistors. Dynamische spannings- en frequentieschaling (DVFS) past spanning en frequentie samen aan, zodat de schakelingen op de gekozen snelheid kunnen blijven werken.

Vermogen en energie beantwoorden verschillende vragen

Vermogen is een hoeveelheid per tijdseenheid, gemeten in watt; één watt is één joule per seconde. Energie voor een taak is het gemiddelde vermogen vermenigvuldigd met de duur:

B neemt tijdens het draaien meer vermogen op maar gebruikt minder energie om de taak te voltooien. De koeling moet de snelheid van warmteproductie aankunnen; batterijverbruik en elektriciteitsverbruik tellen de energie over de tijd op.

Bij vast werk met hetzelfde aantal overgangen, dezelfde spanning en activiteit spreidt alleen de frequentie verlagen die overgangen over meer tijd. Het dynamische vermogen daalt, maar de dynamische energie voor de taak blijft gelijk. De spanning verlagen vermindert ook de energie van elke overgang. Als het statische vermogen gedurende de langere uitvoering blijft bestaan, kan vertragen dat deel van de taakenergie zelfs verhogen.

Lekstroom en niet-actieve hardware

Transistors die in principe uitstaan, laten nog steeds lekstroom door. Kleinere componenten en lagere drempelspanningen maken lekstroom tot een belangrijk ontwerpvraagstuk. Voedingsuitschakeling koppelt de voeding van een niet-actief deel los om het statische verbruik te verminderen.

Een licht belaste server kan nog steeds een aanzienlijk deel van zijn piekvermogen verbruiken. Het verbruik laten meegroeien met nuttig werk, energieproportionaliteit genoemd, is een ontwerpdoel. Een taak snel voltooien en een energiezuinige toestand ingaan kan energie besparen doordat de periode korter wordt waarin lekstroom en ander achtergrondvermogen worden verbruikt. Prestaties en energie-efficiëntie kunnen daardoor samen verbeteren.

Decennialang brachten kleinere transistors zowel meer componenten als sneller schakelen binnen een beheersbaar warmtebudget. De vermogensgrens ontstond toen de spanning niet meer genoeg kon blijven dalen om dat patroon te ondersteunen. Daardoor veranderde de manier waarop ontwerpers nieuwe transistors omzetten in nuttige prestaties.

Het ideale verband van Dennard-schaling

In het ideale schalingsmodel dat Robert Dennard en collega's in 1974 ontwikkelden, beschrijft een factor $k>1$ de verkleining. Afmetingen, capaciteit, spanning en vertraging worden door die factor gedeeld. De frequentie kan met die factor worden vermenigvuldigd. Het dynamische vermogen per transistor verandert daardoor met:

Het oppervlak per transistor daalt ook met het kwadraat van de verkleiningsfactor. Op hetzelfde oppervlak passen zoveel meer transistors, wat het lagere vermogen per component compenseert. De vermogensdichtheid, watt per oppervlakte-eenheid, blijft in dit ideale model ongeveer constant.

Bij een factor 1,4 dalen capaciteit en spanning tot ongeveer 0,71 van hun oorspronkelijke waarde en stijgt de frequentie met factor 1,4. Het vermogen per transistor daalt tot ongeveer 0,51. Er passen ongeveer 1,96 keer zoveel transistors, zodat het totale vermogen op hetzelfde oppervlak ongeveer gelijk blijft.

Waarom de spanning de grootte niet meer volgde

Transistors hebben een bruikbare schakeldrempel nodig. Als de drempelspanning te ver wordt verlaagd, neemt de lekstroom sterk toe. Rond het midden van de jaren 2000 kon de voedingsspanning niet langer in hetzelfde tempo krimpen als de afmetingen van transistors. Bij een vrijwel vaste spanning verhoogt een hogere frequentie het dynamische vermogen en verhoogt het plaatsen van meer actieve transistors op een oppervlak de warmte die moet worden afgevoerd.

De historische cijfers laten de omvang van de eerdere verandering zien: klokfrequenties van desktopprocessors stegen van ongeveer 10 MHz begin jaren 1980 naar 3,8 GHz in 2004, terwijl voedingsspanningen daalden van ongeveer 5 V naar 1 V. Dit zijn globale historische waarden, geen universele specificaties. Ongeveer 100 W was al een moeilijk te koelen vermogensbudget voor veel gangbare ontwerpen uit die periode.

Intels annulering in 2004 van de geplande Pentium 4 van 4 GHz en het Tejas-ontwerp markeerde de omslag naar ontwerpen die rekening hielden met vermogen en naar twee kernen. Klokfrequenties bleven daarna in de orde van enkele gigahertz in plaats van de eerdere snelle stijging te volgen. De microarchitectuur bleef de prestaties van afzonderlijke kernen verbeteren, maar frequentieverhogingen leverden veel minder van de winst.

Beheer het thermische budget

Thermisch ontwerpvermogen (TDP) is een doelwaarde voor het thermische ontwerp die wordt gebruikt om een koeloplossing te dimensioneren onder gespecificeerde bedrijfsomstandigheden. Het is geen momentane vermogensmeting of universeel maximum. Wanneer thermische grenzen worden bereikt, verlaagt thermische snelheidsbegrenzing de werksnelheid om de warmte te verminderen.

Als een chip meer hardware bevat dan binnen het vermogensbudget tegelijk op volle snelheid kan draaien, moeten sommige delen worden vertraagd of uitgeschakeld. Niet gelijktijdig activeerbaar silicium duidt dit verschil aan tussen beschikbare transistors en actieve hardware die tegelijk kan worden gebruikt.

De wet van Moore en Dennard-schaling beschrijven verschillende trends: aantallen transistors tegenover schalingsgedrag waarbij rekening wordt gehouden met vermogen. Het wegvallen van dat laatste betekende niet dat de groei van het aantal transistors stopte. Het obstakel voor het onbeperkt verhogen van de frequentie is vooral vermogen en warmte, niet een plotseling onvermogen van transistors om nog sneller te schakelen.

Een multicoreprocessor plaatst meerdere kernen op één chip. Elke kern voert een instructiestroom uit, terwijl de kernen het hoofdgeheugen en vaak ook sommige caches delen. Gangbare desktop- en laptopontwerpen gingen rond 2005–2006 over op twee kernen, omdat het verhogen van de klokfrequentie van één kern steeds meer vermogen kostte.

Vergelijk twee langzamere kernen met één snellere kern

Bekijk één kern op 4 GHz en 1,2 V tegenover twee kernen op 3 GHz en 1,0 V. Houd de capaciteit per kern en de schakelactiviteit voor deze vergelijking gelijk. Het relatieve dynamische vermogen is:

Bij evenveel werk per cyclus en genoeg onafhankelijk werk voor beide kernen verandert de ideale doorvoer met:

Het paar biedt ongeveer 50% meer doorvoer voor ongeveer 4% meer dynamisch vermogen. Door het kwadratische effect van de spanningsverlaging is de extra kern in dit model betaalbaar. Statisch vermogen, beperkingen van het gedeelde geheugen en coördinatiekosten blijven van belang bij het beoordelen van een volledige chip.

Voor een sequentieel programma dat slechts één nieuwe kern gebruikt, dalen de prestaties tot drie kwart van de oorspronkelijke waarde bij evenveel werk per cyclus. Het duurt vier derde keer zo lang. De twee frequenties van 3 GHz samen “6 GHz” noemen zou die uitkomst verhullen: geen van beide kernen tikt op 6 GHz.

Software moet het werk beschikbaar maken

Vóór de vermogensgrens versnelden een hogere frequentie en overlap door hardware bestaande code vaak zonder grote veranderingen. Extra kernen hebben onafhankelijke instructiestromen nodig. Een programma profiteert daarvan door zijn werk in gelijktijdige taken te verdelen, de toewijzingen in evenwicht te brengen en resultaten te coördineren. Parallelle bibliotheken kunnen die structuur bieden, maar het werk moet nog steeds een bruikbare parallelle vorm hebben.

Parallellisme op instructieniveau laat instructies binnen een stroom overlappen met hardware- en compilertechnieken zoals pipelining en meervoudige instructie-uitgifte. Parallellisme op threadniveau voert verschillende threads uit op verschillende kernen. Dit zijn verschillende bronnen van gelijktijdigheid: de eerste garandeert niet dat een programma elke kern kan bezighouden.

Onafhankelijke serververzoeken leveren vanzelf veel stromen op, zodat multicoreverwerking de doorvoer kan verbeteren, ook als elk verzoek sequentieel blijft. Om de berekening van één verzoek te verkorten, is parallellisme binnen dat verzoek nodig. De sequentiële fractie daarvan legt dan de grens van Amdahl op.

Gebruik transistors voor efficiënt werk

Meer transistors kunnen grotere caches, meerdere algemene processorkernen of gespecialiseerde hardware ondersteunen. GPU's en domeinspecifieke hardwareversnellers richten zich op werklasten zoals grafische verwerking, machinaal leren en videocodering. Chips kunnen ook snelle kernen met hoog vermogen combineren met kleinere, efficiëntere kernen, zoals in de big.LITTLE-ontwerpen van Arm.

Binnen een vast vermogensbudget vergelijkt prestatie per watt de nuttige prestatie met het opgenomen vermogen. SPEC CPU 2026 ondersteunt naast prestatiemaatstaven ook energiemetingen. Een goede ontwerpbeslissing houdt rekening met de voltooiingstijd van de werklast, de energiekosten en het vermogen dat het systeem kan volhouden.