Er automatiseret tilknytning af tråde til CPU-kerner mulig?

Automatisering tilknytning af tråde CPU-kerner kan afhjælpe et tungt arbejde med manual forbedring af softwareydelsen i form af pinning. Men det kræver et vanskeligt blik for fremtidens behov, påpeger Version2-blogger.

Topperformance af applikationer og software er afgørende i kampen om brugerne. En del af indsatsen kræver, at man tilknytter tråde i programmer til CPU-kernerne på en måde, så man undgår overbelastning af enkelte kerner og dermed dårligere ydelse.

Udfordringen er, at programmører i dag gennemfører parallel programmering på flere distribuerede systemer for at sikre, at applikationer kan skaleres på tværs af flere motorer eller hybride elementer, der blander CPU'er med FPGA'er, GPU'er, DSPs, eller andre motorer - alt sammen forbundet i et netværk.

Inde i hver motor er antallet af kerner og tråde vokset dramatisk det seneste årti, og hver socket er nu lige så kompleks som et symmetrisk multiprocessing system var for to årtier siden.

Med mange CPU-kerner og sædvanligvis flere tråde per kerne til at eksekvere software, kan det vanskeligt at opnå en tilstrækkelig ydelse.

Hos verdens finans-it giganter, i High Performance Computing (HPC) centre, og hos database- og middleware-udbydere, er de kvikkeste programmører ofte ud i alle hjørner med blyant og papir for at kortlægge indbyrdes afhængigheder i koden og affiniteter mellem trådene, skriver The Next Platform.

Når man har kortlagt disse afhængigheder, kan knytte softwareprocesser og tråde til bestemte CPU-kerner for at optimere deres ydeevne. Ved at undgå for mange tunge tråde knyttes til enkelte CPU-kerner.

Manuel tråd management er tidskrævende

Problemet er, at ofte kan tage alt fra to til otte uger at knytte applikationer og deres tråde til specifikke kerner i et system.

I de store finansielle institutioner bliver mange applikationer opdateret mindst en gang hver måned og nogle gange så meget som 200 gange om året, så her kan disse tuningsprocesser tage uger til måneder.

Det betyder, at koden aldrig er så optimeret, som den burde være.

I dag findes der efterhånden værktøjer, der kan automatisere denne tilknytning til trådene.

Eksempelvis fra Pontus Networks, som blev etableret i 2010 som en konsulentvirksomhed med speciale i optimering af latency sensitive applikationer

Selskabet udvikler værktøjet Pontus Vision Thread Manager og ansøgte om deres første patenter om automatiseret tråd tilknytning (pinning) i august 2014.

Hele ideen er at fjerne den menneskelige flaskehals og sikre hurtigere forbedring af softwareafviklingen.

Version2-blogger Mikkel Lauritsen er også CTO i app-udviklingsfirmaet IntraMed, som laver applikationer rettet mod patienter med kroniske sygdomme.

Han mener, at det er svært – nærmest umuligt - at lave pinning og samtidig sikre optimal resourceudnyttelse. Fordi det forudsætter en optimal fordeling af tråde på CPU-kernerne.

»Det kræver, at man kan forudsige, hvad der sker i fremtiden. Hvis man ikke kan det - og det har jeg i hvert fald personligt svært ved - vil man altid kunne komme til at gruppere tråde, som kører længe og generelt er ressourcekrævende, på en kerne, og andre tråde, som hurtigt stopper, på en anden, og så bliver man alligevel nødt til at flytte rundt på trådene,« siger han.

Du kan læse mere om anvendelsen af sådanne værktøjer her

Følg forløbet

Kommentarer (15)

Ivo Santos

I følge denne side er størrelsen på en i7 xeon's level 1 cache stadig på 32KB, den pågældende cpu blev i følge den pågældende side introduceret i maj 2015
Intel Xeon E7-4809 v3 specs

Det er vel fint nok at man kan optimere på CPU niveau, men der er andre muligheder og en større level 1 cache burde kunne give en forbedrede ydelsesniveau. det samme kan man vel sige om level 2 cache.

Ovenstående er blot en tanke fra min side.

Troels Henriksen

Det er vel fint nok at man kan optimere på CPU niveau, men der er andre muligheder og en større level 1 cache burde kunne give en forbedrede ydelsesniveau. det samme kan man vel sige om level 2 cache.

En større cache er også langsommere. Det gør sig gældende for stort set alle typer lager - det er derfor man typisk har indført flere cache-niveauer frem for at gøre hvert niveau så meget større.

Johnnie Hougaard Nielsen

Det er vel fint nok at man kan optimere på CPU niveau, men der er andre muligheder og en større level 1 cache burde kunne give en forbedrede ydelsesniveau. det samme kan man vel sige om level 2 cache.

Det er jo indlysende at en CPU med større ydelse kan give forbedret ydelsesniveau. Men en af grundene til at en større L1 cache er langsommere er at den fysisk er større. Det vil sige længere elektriske ledere, både internt i cache og til CPU. Det må antages at chip designerne arbejder på livet løs på at finde en egnet vægtning her, og hvor stor L1 cache det kan betale sig at lave.

Mere generelt er det dog altid en mulighed for at forbedre ydelsen (som fx svartider på mikrosekundniveau eller under) ved at binde sig til en bestemt CPU kerne, og dennes cache - og forhindre andre i at bruge denne. Hvis dette kan opnås uden at skifte hardware (til noget som endnu ikke findes), kan det give stor fordel at lave tuning på dette detaljerede niveau.

Jeg har selv engang leget med at forbedre svartider på fysiske disk, ved at flytte filer rundt, så der ikke skulle for store armbevægelser til. Eller lægge små filer med høj brug på en del af disken med faste læse/skrivehoveder - uden disse kunne det være smart i midten af disken.

Jesper Louis Andersen

Jeg er lidt nysgerrig, faktisk. Hvordan fungerer automatisk pinning? Er det statistik forecasting baseret på faktiske kørsler eller ren kodeanalyse?

En simpel metode, der anvendes af Occam-Pi, er at heuristisk lede efter de processer der kommunikerer meget med hinanden og derfor ofte blokerer hinanden. Dem kan du med fordel placere i samme batch og så ellers skedulere batches som en enhed. Hvis du heuristisk så kan forme nye batches og bryde for store batches op, så har du en dynamisk model der i praksis virker temmeligt godt.

Jesper Louis Andersen

I følge denne side er størrelsen på en i7 xeon's level 1 cache stadig på 32KB, den pågældende cpu blev i følge den pågældende side introduceret i maj 2015
Intel Xeon E7-4809 v3 specs

Hvis du gør cachen større, så sker der det som Troels siger: Det tager længere tid at hente data langt væk i cachen og ind i registrene. Det betyder så at du nu bruger 3-4 cycles på at få data ind i registerbanken i stedet for de nuværende 1-2 stykker. Som konsekvens har programmet flere cycles hvor det staller fordi det venter på data fra L1. Det kan sandsynglivis ikke betale sig at have en større cache fordi stall cycles er meget værre.

Bemærk iøvrigt at du har splittet en moderne L1 i instruktions or data cache. Det betyder at du kan placere de 2 cache-banker forskellige steder i CPUen og det kan gøre at du kan komme til cachen hurtigere. Nogen eksperimentelle CPU designs arbejder med at splitte cachen endnu mere op.

Ivan Skytte Jørgensen

En større cache er også langsommere. Det gør sig gældende for stort set alle typer lager - det er derfor man typisk har indført flere cache-niveauer frem for at gøre hvert niveau så meget større.


Man kan også dele cachen op og dermed få 2 mindre og hurtigere caches.

En ting, som undrer mig, er hvordan HP's PA-RISC 8700+ kunne have 1.5MB L1 I-cache og 1.5MB L1 D-cache, med en latency på 2 clockcycles. Og så 32MB L2-cache oveni. Alt dette tilbage i 2002.

En moderne xeon har circa 64KB L1 cache, hvor et L1-cache hit koster circa det samme som 4 instruktioner.

HP må have gjort noget rigtigt.

Johnnie Hougaard Nielsen

En ting, som undrer mig, er hvordan HP's PA-RISC 8700+ kunne have 1.5MB L1 I-cache og 1.5MB L1 D-cache, med en latency på 2 clockcycles. Og så 32MB L2-cache oveni. Alt dette tilbage i 2002.

Du skal ikke tælle clockcycles, men nanosekunder. Og picosekunder.

Uden at have nærstuderet tal, vil jeg antage at forklaringen simpelthen er at den langsommere clock gav bedre tid til at nå så langt væk som til hjørnerne af en fysisk større cache. Uafhængig af antal clockcycles.

En moderne xeon har circa 64KB L1 cache, hvor et L1-cache hit koster circa det samme som 4 instruktioner.

Den højere effektivitet i kraft af længere pipelining (med parallelisering) gør at tabet ved at skulle "ud i verden" fylder mere målt i instruktioner. Igen er det mere spændende at måle tid, i stedet for at tælle de arbitrære måder den bliver hakket i bidder på.

Jesper Louis Andersen

En ting, som undrer mig, er hvordan HP's PA-RISC 8700+ kunne have 1.5MB L1 I-cache og 1.5MB L1 D-cache, med en latency på 2 clockcycles. Og så 32MB L2-cache oveni. Alt dette tilbage i 2002.

En moderne xeon har circa 64KB L1 cache, hvor et L1-cache hit koster circa det samme som 4 instruktioner.

HP må have gjort noget rigtigt.

HP gjorde i den grad noget rigtigt:

  • 875 Mhz clock speed, så 2 cycles latency giver dig mere tid til at hente data ud af cachen.

  • PA-RISC bruger virtuel mapping af cachen, så dit TLB lookup kan køre i parallel med dit cache lookup. Det gør Core i7 ikke logisk set (i.e., de kunne godt gøre det i det skjulte, men se næste punkt).

  • HP-UX antager ikke, i modsætning til andre operativsystemer, at din cache er physical mapped. Så du tager højde for muligheden for aliasing i din cache fra OS'ets side. Det gør at du kan lave en cache hvor du ikke er begrænset af page-size, som du ellers ville være (da du dermed kan bryde med antagelsen om 1-1 physical mapping). I en Windows/Linux-verden kan du pt kun løse problemet ved at øge cachens associativitet når du gør den større, og det betyder tabt latency. HP-UX havde ikke denne dumme begrænsning.

  • PA-RISC var designet for workloads der virkeligt havde brug for disse store caches.

  • PA-RISC var temmeligt dyr. En 2.25 megabyte stor cache på en chip for 15 år siden har fyldt rigtigt meget og har kostet en hel del.

Pt lider vi under at den "vindende" arkitektur er en dinosaur. Vi har ringet, men meteoren er ikke kommet forbi endnu.

Jesper Louis Andersen

Du skal ikke tælle clockcycles, men nanosekunder. Og picosekunder.

Og endnu bedre: parallelisme.

Du har så mange steder hvor en moderne CPU er i stand til at køre uafhængige instruktioner i parallel at man i praksis er nødt til at bruge de performancecounters der i CPUen og måle på hvor lang tid det tager at gøre ting. De moderne CPUers out-of-order execution er efterhånden så god at visse optimeringer i code-emission ikke betyder det store mere.

Johnnie Hougaard Nielsen

Jeg undrer mig blot lidt over at HP i 2002 kunne lave en så stor L1 cache med circa samme (nanosekund-)latency som andre chipfabrikanter kunne på samme tidspunkt.

Det handler ikke om "kunne" men om "gjorde". Som nævnt af Jesper var PA-RISC "temmeligt dyr". Med mindre det primære mål er single-core performance, kan det siges at samme omkostning ville give betydeligt mere benefit med ekstra kerner, måske ekstra chips.

Nu om dage er der ikke ret mange der (til store workloads) kikker på hvor meget hver core kan udrette, mere på hvad en vis ydelse koster i indkøb, køling og strøm. Det er jo ikke for sjov at der kikkes på ARM som server processor, selv om hver kerne har ikke så lidt lavere ydelse end i en Xeon. Hvis det samlede regnestykke er til fordel for ARM, har fx Google stor anledning til at skifte. Og de er den største kunde (4%) til de meget lukrative server processorer fra Intel, ud over de største af dem som sælger dem videre med en server udenom.

Troels Henriksen

Udover ARM, så kigger Google (og andre) også på POWER i kraft af OpenPOWER-konsortiet. Her er gevinsten dog ikke strømbesparelse (en POWER bruger endnu mere end x86), men god hardware-flertrådning (tænk HyperThreading) og en mere åben platform.

Log ind eller opret en konto for at skrive kommentarer

JobfinderJob i it-branchen