CPU-hurtigbufferoptimalisering og ytelse i Windows

Informatec Digital » Ressurser » CPU-hurtigbufferoptimalisering og ytelse i Windows

La CPU-hurtigbufferoptimalisering Det er et av de temaene som skiller kode som «fungerer» fra kode som «flyr». Når vi forstår hvordan minne er organisert, hvilke tilgangstider hvert nivå håndterer, og hvordan maskinvaren oppfører seg, kan vi oppnå massive ytelsesforbedringer uten å bytte maskiner.

I mellomtiden lider et betydelig antall Windows-brukere av et mer hverdagslig problem: PC-ene deres er trege. Og ofte ligger roten til problemet nettopp der, i ineffektiv bruk av minne, hurtigbuffer og selve CPU-en. Med en kombinasjon av god lavnivådesign (datastrukturer, minnetilgangsmønstre) og praktiske innstillinger i Windows (rengjøring, oppdatering, strømmoduser osv.) kan man oppnå svært merkbare forbedringer, fra små økninger på 5 % til hopp på 30–40 % i visse scenarier.

Minnehierarki og latenser: hvorfor hurtigbufferen styrer

Før vi begynner å finjustere kode eller konfigurere Windows, må vi forstå én ting tydelig: ikke alt minne er skapt like. Forskjellen mellom å få tilgang til L1-, L2-, L3-hurtigbuffere, RAM eller disk er enorm, og mange hurtigbufferoptimaliseringer er bokstavelig talt basert på dette. unngå å gå til lave nivåer alt mulig.

I en moderne prosessor er typiske tilgangstider (i størrelsesorden) omtrent som følger: en tilgang til L1-hurtigbuffer Det er rundt et halvt nanosekund, en feil i en hoppforutsigelse tar flere nanosekunder, L2 Det er rundt 7 ns, mens det å nå hovedminnet kan overstige 100 ns. Hvis vi beveger oss utenfor enheten (nettverk, SSD, mekanisk harddisk), skyter tallene i været til hundretusenvis eller millioner av nanosekunder.

Denne store forskjellen er det som gjør det så viktig å organisere data riktig, redusere cache-tab og designe sekvensielle tilgangsmønstre. En løkke som ligger i L1-cache vil være betydelig raskere enn en som konstant har tilgang til RAM eller SSD, selv om de utfører "den samme" oppgaven fra et logisk synspunkt.

Videre er CPU-hurtigbufferen organisert i flere nivåer: L1, veldig liten og ekstremt rask; L2, større og noe tregere; og L3, enda større, ofte delt mellom kjerner. Tanken er å holde de "varme" dataene (dataene som brukes ofte) lett tilgjengelig og flytte resten til tregere nivåer. Som utviklere kan vi bidra til at dette skjer naturlig med god datastrukturdesign og med forutsigbar tilgang.

Hva er cache, og hvorfor påvirker det ytelsen?

Hurtigbufferen, i enhver kontekst (CPU, disk, web…), er en rask lagring av nylig brukte dataI stedet for alltid å bruke den tregeste kilden, beholder vi en kopi av det som mest sannsynlig vil bli gjenbrukt. Dette forkorter responstiden og reduserer belastningen på primære ressurser.

Generelt brukes mellomlagring for å øke hastigheten på tilgangen og forbedre brukeropplevelsen. I praksis lar det også systemet utføre mer arbeid med samme maskinvare: mindre venting, færre blokkeringer og færre køer. Det er derfor det brukes i CPUer, disker, nettlesere, distribuerte systemer og praktisk talt all programvare som håndterer data intensivt.

En typisk PC inneholder flere typer hurtigbuffer: diskbuffer (RAM som lagrer data fra harddisken), nettbuffer (statiske nettleserressurser) og CPU-hurtigbuffer (L1, L2, L3). De jobber alle med den samme grunnleggende ideen: å lagre det som sannsynligvis vil bli nødvendig senere, og unngå å gjenta langsomme operasjoner.

Typer hurtigbuffer: disk-, nett- og CPU-hurtigbuffer

Innenfor et virkelig system konvergerer flere mellomlagringsmekanismer, hver på sitt eget nivå. Å forstå dem hjelper både med bedre programmering og med å diagnostisere hvorfor en PC yter dårligere enn forventet.

Diskbuffer

Diskbufferen er et minneområde (vanligvis RAM) der operativsystemet lagrer data som nylig er lest eller skrevet til diskenNår applikasjonen ber om disse dataene igjen, sjekker systemet først hurtigbufferen: hvis den er der, er tilgangen mye raskere enn å gå til disken, spesielt hvis vi snakker om mekaniske disker.

Denne mekanismen reduserer lastetidene drastisk, reduserer antallet fysiske lese- og skriveoperasjoner, og dermed også forlenger levetiden til diskenI scenarier med gjentatt tilgang til de samme filene (databaser, servere, tunge applikasjoner), utgjør diskbufring en stor forskjell.

Nettbuffer

I nettleseren lagrer nettbufferen midlertidig bilder, stilark, JavaScript og andre ressurser. Takket være dette kan nettleseren, når du besøker en side igjen eller navigerer mellom seksjoner på samme nettsted,... hente fra det du allerede har lagret istedenfor å bestille den på nett igjen.

Resultatet er todelt: kortere lastetider for brukeren og mindre båndbreddeforbruk, både på tilkoblingen din og på serveren som leverer innholdet. Men hvis hurtigbufferen ikke administreres riktig, kan det oppstå utdaterte ressurser, og derfor er det noen ganger lurt å tømme den.

CPU-hurtigbuffer: L1-, L2- og L3-nivåer

Kronjuvelen når det gjelder ytelse er CPU-hurtigbufferen. Moderne prosessorer inkluderer flere hierarkiske nivåer som er utformet for å minimere latens for data og instruksjonstilgang. Generelt sett er L1 den minste og raskeste, L2 er den mellomliggende, og L3 er den største og tregeste, ofte delt.

La L1-hurtigbuffer Den er vanligvis delt inn i instruksjoner og data, med typiske størrelser på noen titalls kB per kjerne. Den er ekstremt rask og brukes til de mest umiddelbare oppgavene. L2-hurtigbuffer Den har større kapasitet (hundrevis av KB til flere MB) og fungerer som en L1-sikkerhetskopi. L3-hurtigbuffer Den kan nå flere MB eller titalls MB, delt av flere kjerner, og fungerer som det siste nivået før den går til RAM.

Når minnetilgangsmønsteret er rimelig sekvensielt eller forutsigbart, er maskinvaren i stand til å forutse det og bringe dataene til disse hurtigbuffernivåene. Når det er kaotisk, fullt av tilfeldige hopp og spredte strukturer, bruker prosessoren for mye tid venter på minne og CPU-en blir «kjedelig». Det er her optimalisering på kodenivå kommer inn i bildet.

Optimaliser datastrukturer for CPU-hurtiglagring

Mye av ytelsen avhenger av hvordan vi designer datastrukturene våre. Det er ikke det samme å ha et gigantisk objekt med varme og kalde felt blandet sammen som det er å skille det som brukes ofte fra det som sjelden brukes. Hver hurtigbufferlinje som bringes til prosessoren har en kostnad; hvis vi fyller disse linjene med ubrukelig data, kaster vi bort båndbredde.

Grupper varme data og separer kalde data

En nøkkelstrategi er å identifisere hvilke felt i en struktur som brukes i nesten alle operasjoner («varme» data) og hvilke som bare brukes av og til («kalde» data). Førstnevnte bør å være sammen i minnet og, om mulig, få plass til én eller noen få hurtigbufferlinjer. Sistnevnte kan være i en separat struktur, referert til av en peker eller indeks.

For eksempel, i stedet for å ha et brukerobjekt med lange strenger (navn, biografi, e-post) blandet med flagg eller markører som kontinuerlig sjekkes, er det bedre å gruppere de "populære" dataene (id, siste innlogging, aktiv status) i en kompakt struktur og la resten av informasjonen være i en separat "detaljstruktur". På denne måten, når koden itererer gjennom en liste over brukere for å sjekke en status eller markør, er hurtigbufferlinjene nesten fullstendig fylt med relevante data.

Reduser fyllstoff og utnytt hver linje bedre

En annen kampfront ligger i den fysiske utformingen av strukturene: rekkefølgen på feltene og typene deres. På grunn av justering kan blanding av typer av forskjellige størrelser på en uordnet måte introdusere utfyllingsbyte som bare tjener til å sløse med minne og, enda verre, hurtigbufferlinjer.

Hvis vi endrer rekkefølgen på en datastruktur for å gruppere store typer først (f.eks. doubles eller int64_t), deretter mellomstore typer, og til slutt de minste typene (bool, char), reduserer eller eliminerer vi vanligvis mye av utfyllingen. Dette gjør at flere elementer får plass per hurtigbufferlinje, noe som reduserer belastningen på minnehierarkiet og sannsynligheten for minnetap.

Velg tilstøtende beholdere

Beholderne som oppbevarer varene i sammenhengende minneVektorer, som en type array, er generelt mye mer hurtigbuffervennlige enn strukturer basert på sparsomme noder koblet sammen av pekere (trær, klassiske koblede lister osv.). Når man krysser en vektor, kan maskinvaren perfekt forutsi neste tilgang og forhåndslaste de følgende hurtigbufferlinjene.

I motsetning til dette distribuerer strukturer som trebaserte kart eller lenkede lister nodene sine over heapen, noe som tvinger CPU-en til å utføre kontinuerlig pekerjakt. Hvert hopp kan resultere i et cache-miss og en kostbar tur tilbake til hovedminnet. Det er derfor mange moderne biblioteker tilbyr tette hash-kartåpne tabeller og andre containere som prøver å holde dataene så kompakte som mulig.

Nettlagring for små samlinger

Mange algoritmer involverer svært små samlinger (noen få heltall, noen få strukturer) som stadig opprettes og ødelegges. Hvis hver av disse forårsaker en heap-allokering, pådrar vi oss ikke bare minneadministrasjonskostnader, men har også data spredt over RAM. Løsningen er å bruke containere med nettbasert lagring for små størrelser.

Denne typen container reserverer plass til 8 eller 16 elementer direkte i selve objektet. Så lenge denne grensen ikke overskrides, er det ikke nødvendig å få tilgang til heapen, og dataene forblir knyttet til resten av funksjonen eller klassetilstanden, noe som er svært gunstig for mellomlagring.

Tilgangsmønstre: fra AoS til SoA og bruk av bitsett

Selv med velstrukturerte hurtigbuffere, bestemmer datatilgangsmønsteret i stor grad ytelsen. Det er ikke det samme å navigere gjennom en array sekvensielt som det er å hoppe fra én adresse til en annen basert på en liste med pekere. Det finnes noen tilbakevendende teknikker for å maksimere hurtigbufferutnyttelsen.

Strukturmatrise (AoS) vs. strukturmatriser (SoA)

Et klassisk mønster er overgangen fra et «array of structures» (AoS)-design til en «array structure» (SoA). I ​​AoS er hvert element et objekt med mange felt (for eksempel posisjonen og massen til en partikkel), og disse elementene lagres sekvensielt. Når du bare trenger å lese en del av disse feltene (for eksempel posisjonen), blir du tvunget til å laste inn hurtigbufferlinjer som også inneholder ubrukte data.

I SoA, derimot, er de forskjellige attributtene separert i parallelle matriser: én for x, en annen for y, en annen for z, en annen for masse, osv. Dermed, hvis en algoritme bare oppdaterer posisjonene, berører den bare koordinatmatrisene, og hurtigbufferen er ikke forurenset med irrelevant informasjonVidere favoriserer denne designen vektorisering og bruk av SIMD-instruksjoner.

Bitssett og referanser etter indeks

For små domener (f.eks. flagg fra 0 til 255) er det mye mer effektivt å bruke et bitsett enn en hash-basert settstruktur. Et bitsett på 256 posisjoner opptar bare noen få titalls byte og muliggjør svært raske, fullstendig sammenhengende og hurtigbuffervennlige operasjoner, i stedet for å måtte løse kollisjoner i en hashtabell.

På samme måte, erstatt pekere med indekser i sammenhengende matriser Det kan redusere størrelsen på strukturene (32-bits indekser i stedet for 64-bits pekere) og forbedre hurtigbufferkoherens. I stedet for noder spredt over heapen, lagres en vektor av noder, og de pekes til etter posisjonen sin, noe som letter sekvensiell gjennomgang.

Forhåndshenting: når man skal komme seg i forkant av arbeidet

I tillegg til forhåndshenting av maskinvare, som forsøker å forutse sekvensielle tilgangsmønstre, har vi instruksjoner for forhåndshenting av programvare for forhåndsinnlasting av data i spesifikke tilfeller. Dette gir mening når mønsteret er forutsigbart, men ikke strengt lineært, slik det skjer i hash-tabeller eller lenkede lister.

Den generelle ideen er enkel: mens du behandler element i, instruerer du maskinvaren til å bringe element i+1 (eller en fremtidig blokk) inn i hurtigbufferen. Når du når det elementet, er sannsynligheten for at det allerede er i L1 eller L2 høy, og ventetiden reduseres. Dette kan implementeres med kompilatorprefetch-primitiver eller spesifikke biblioteker.

Det er imidlertid ikke noe poeng i å bruke eksplisitt forhåndshenting i fullstendig sekvensielle tilganger, fordi maskinvaren allerede håndterer det automatisk. Faktisk kan det å legge til unødvendig forhåndshenting skitne opp cachen og forverre ytelsen. Som nesten alltid er tilfelle med ytelse, er det best å måle før og etter.

Retningslinjer for hurtigbufret plassering, erstatning og forhåndshenting

På et mer teoretisk nivå er hurtigbuffersystemer basert på retningslinjer for hvor data skal lagres, når de skal hentes og hvilke data som skal fjernes når det ikke er nok plass. Selv om disse detaljene administreres av maskinvaren eller operativsystemet, hjelper det å forstå dem med å tolke visse uvanlige atferder.

Når det gjelder plassering, kan ordninger brukes av minnesegmentering eller settassosiativ allokering, der hver hovedminneadresse bare kan tilordnes til et delsett av hurtigbufferen. Dette påvirker antall konflikter og sannsynligheten for at to adresser overlapper hverandre i hurtigbufferen.

Når det gjelder tømming av hurtigbuffer (hva som skjer når det oppstår et hurtigbuffertap), kommer erstatningspolicyer inn i bildet: LRU (Minst brukte data), FIFO, eller til og med tilfeldig erstatning. LRU prøver å beholde de sist brukte dataene i hurtigbufferen, forutsatt at de vil være nødvendige igjen, mens FIFO ganske enkelt forkaster de eldste dataene. Hver policy har sine fordeler avhengig av det faktiske tilgangsmønsteret.

I forhåndshentingsdelen finnes det mekanismer basert på historiske mønstre: hvis maskinvaren oppdager at hver tilgang er forskjøvet, for eksempel alltid med 64 byte, vil den ha en tendens til å forutse tilstøtende blokkerI andre tilfeller brukes forhåndshenting av plass (henting av en hel blokk selv om du bare forespurte en del av den) for å minimere antall turer til hovedminnet.

Måling og profilering av hurtigbufferatferd

Å optimalisere uten å måle er som å gå inn i blinde. Det finnes verktøy for ytelsesanalyse som lar deg se spesifikke hurtigbuffermålinger: referanser, L1-bommer, bommer på siste nivå av hurtigbuffer (LLC), bommer i prosent osv. Disse målene indikerer om endringene dine faktisk forbedrer situasjonen.

Hvis for eksempel prosentandelen av bommer i nivå 1 er rundt 2–3 %, anses det vanligvis som rimelig, mens svært høye bommertall i cachen på siste nivå kan indikere problemer med romlig eller tidsmessig plasseringÅ kombinere disse tallene med CPU- og minneprofiler bidrar til å oppdage hvilke deler av koden som legger mest press på minnehierarkiet.

Hurtigbuffer og ytelsesoptimalisering i Windows

Utover selve koden lurer mange brukere på hvorfor Windows-PC-en deres kjører så sakte hvis den «i teorien» har en god CPU og RAM. Noe av svaret ligger i selve systemet, i de innebygde applikasjonene og opphopningen av digitale søppelfiler. De bruker CPU, minne og cache. konstant, noe som gir færre ressurser til viktige oppgaver. Ved å bruke flere spesifikke optimaliseringer i Windows 10 og Windows 11 er det mulig å frigjøre CPU- og RAM-ressurser (For eksempel ved å konfigurere virtuelt minne), reduserer bakgrunnsprosesser og forbedrer systemets evne til å mellomlagre relevante data. Avhengig av startsituasjonen kan disse forbedringene variere fra mindre justeringer til svært merkbare endringer i den generelle ytelsen.

Oppdater Windows og drivere

Et veldig grunnleggende trinn som mange forsømmer er å holde både operativsystemet og driverne oppdatert. Windows-oppdateringer bringer ikke bare sikkerhetsoppdateringer: de inkluderer ofte forbedringer i ressursforvaltning, rettelser av minnelekkasjer og kjerneoptimalisering.

Fra Windows-innstillingspanelet (Start > Innstillinger > Oppdatering og sikkerhet > Windows Update) kan du søke etter både generelle oppdateringer og valgfrie pakker, inkludert ikke-kritiske drivere som kan optimalisere ytelsen til CPU-en, GPU-en eller brikkesettet. Installasjon av disse komponentene kan løse flaskehalser eller stabilitetsproblemer som direkte påvirker hvordan hurtigbuffer og minne utnyttes.

Deaktiver P2P-distribusjon av oppdateringer

Siden Windows 10 kan systemet laste ned og dele oppdateringer ved hjelp av en P2P-mekanisme med andre datamaskiner. Selv om dette systemet er genialt, betyr det at datamaskinen... bruker CPU, nettverk og disk for å hjelpe til med å distribuere oppdateringer, noe som ikke alltid er ønskelig.

Hvis du deaktiverer «Leveringsoptimalisering» i Windows Update, hindres PC-en i å levere eller laste ned oppdateringsfragmenter til andre datamaskiner. Dette frigjør ressurser, reduserer bakgrunnsaktivitet og kan forbedre den generelle ytelsen, spesielt på mindre kraftige systemer.

Frigjør diskplass og fjern søppelfiler

Når disken er full eller nesten full, har Windows mindre plass til å bla gjennom og opprette midlertidige filer, noe som til syvende og sist påvirker ytelsen. Bruk det innebygde verktøyet for Disk Opprydding Den lar deg slette midlertidige filer, rester av oppdateringer, elementer fra papirkurven og andre data som ikke lenger er nødvendige.

I tillegg til dette opprydningsverktøyet anbefales det å tømme papirkurven regelmessig og bruke Windows-lagringsalternativer for å slette akkumulerte midlertidige filer. Jo mindre plass det er på systemstasjonen, desto mer effektivt vil minnesystemet fungere, og desto mer effektivt vil diskbufferen fungere.

Optimaliser oppstarts- og bakgrunnsprogrammer

En av de største fiendene til CPU-en og hurtigbufferen på en PC som brukes daglig, er programmer som starter automatisk og kjører i bakgrunnen: synkroniseringsprogrammer, oppdateringsprogrammer, små verktøy som vi knapt bruker, osv. Selv om de kan virke lette, legger hver av dem til tråder, minne, disktilgang og hurtigbufferforbruk.

Fra Oppgavebehandling eller med Sysinternals for prosesskontrollPå Hjem-fanen er det mulig deaktiver unødvendige apper for å forhindre at de lastes inn automatisk. I personverninnstillingene kan du også kontrollere hvilke programmer som får kjøre i bakgrunnen. Å redusere denne listen forbedrer ikke bare oppstartstiden, men reduserer også den kontinuerlige belastningen på CPU og RAM.

Reduser grafiske effekter og varsler

Vindusanimasjoner, gjennomsiktighet og andre visuelle utsmykninger bruker ressurser. På eldre eller mindre kraftige datamaskiner kan det være gunstig å justere Windows-innstillingene for å prioritere ytelse fremfor utseende. Dette gjøres gjennom systemets avanserte alternativer, i ytelsesdelen, ved å velge konfigurasjonen som favoriserer hastighet.

På samme måte kan et overskudd av varsler mette brukeren og teametDeaktivering av unødvendige varsler rydder ikke bare opp brukeropplevelsen, men forhindrer også at bakgrunnsprosesser eller kontroller utløses for ofte.

Strømmoduser, dvalemodus og topp ytelse

Windows har flere strømstyringsplaner som direkte påvirker hvordan CPU-en administreres: om batterilevetid eller ren ytelse prioriteres. På stasjonære og bærbare datamaskiner som er koblet til strømnettet, er det vanligvis lurt å gjennomgå disse innstillingene.

El rask start Rask oppstart kombinerer funksjoner for avstenging og dvalemodus for å øke oppstartstiden ved å forhåndslaste deler av kjernen og driverne før avslutning. Aktivering kan redusere oppstartstiden betydelig, men det anbefales å deaktivere den midlertidig hvis det forårsaker problemer med oppdateringer eller BIOS-tilgang.

På den annen side er det en skjult «maksimal ytelse»-plan Dette tvinger CPU-en og andre komponenter til å jobbe mindre effektivt, og prioriterer energisparing. Å aktivere det kan gi litt mer kapasitet til intensive oppgaver, men på bekostning av økt varme, viftestøy og strømforbruk.

Effektiv håndtering av plass og minne i systemet

I tillegg til regelmessig rengjøring og kontroll av innebygde programmer, finnes det andre måter å bedre utnytte datamaskinens fysiske ressurser og dermed CPU- og diskbufferen.

Å ha et skrivebord som er rotete med ikoner, snarveier, mapper og filer er ikke bare visuelt rot: Windows må håndtere alt dette, noe som gir litt ekstra arbeidsmengde. rimelig rent skrivebord Å organisere filer i mapper på stasjoner er en enkel praksis som bidrar til et lettere miljø.

Det hjelper også å bruke skylagringsløsninger for visse filer, noe som reduserer mengden lokal lagring som brukes. Forutsatt at dette gjøres fornuftig (uten å være helt avhengig av internettforbindelsen), kan det lokale systemet holdes mindre belastet og ha mer fleksibilitet.

Spesifikke teknologier: ReadyBoost, overklokking og maskinvare

På systemer med mekanisk harddisk og begrenset RAM inkluderer Windows teknologier som ReadyBoost, som lar deg bruke en rask USB-stasjon som en slags ekstra hurtigbuffer. Selv om det ikke er en magisk løsning, kan det i visse konfigurasjoner gi en ytelsesøkning. avlaste noe av trykket på disken.

I den andre enden av spekteret kan avanserte brukere overklokke CPU-ene sine ved hjelp av verktøy som Intel Extreme Tuning Utility (for ulåste prosessorer). Å øke klokkehastigheten øker ytelsen, men øker også temperatur og strømforbruk, med en reell risiko for ustabilitet og skade hvis spenning og kjøling ikke håndteres nøye.

Når alle programvareoptimaliseringer er til kort, er det på tide å vurdere maskinvareoppgraderinger: bytte ut en harddisk med en SSD, utvide RAM, eller til og med endringsbehandler eller hele systemet. En SSD, spesielt, forvandler den oppfattede ytelsen til systemet, ettersom den reduserer disktilgangstiden drastisk, noe som igjen gjør at diskbufferen og det virtuelle minnet fungerer mye jevnere.

Sammen, kombiner god design av datastrukturer og minnetilgangsmønstre Å utnytte CPU-hurtigbufferen med en nøye Windows-konfigurasjon (oppdatert, lett, uten søppel eller unødvendige prosesser, med riktig strømstyringsplan og om nødvendig med små hjelpemidler som ReadyBoost eller maskinvareforbedringer) lar deg få mye mer ut av den samme datamaskinen, oppnå applikasjoner som reagerer med smidighet og et system som føles merkbart raskere uten behov for "magi" eller esoteriske triks.