Aarhusiansk forsker flytter dine beregninger fra CPU til GPU - og 50-dobler hastigheden

GOTO: Der sidder en heftig talknuser på selv almindelige grafikkort, som kan bruges til lynhurtige beregninger. Men det er stadig ikke helt mainstream at slippe alle kræfterne fri.

Tunge beregninger behøver ikke køre i timevis på en CPU, presset til det yderste, når der få centimeter derfra sidder en grafikchip, der er meget bedre egnet til den slags.

Sender man i stedet en regneopgave til grafikkortet, kan ventetiden skæres ned til få procent - fra timer til minutter, hvis opgaven er egnet til parallelle beregninger. Det fortæller Jesper Mosegaard, forskningschef på Alexandra Instituttet i Aarhus.

»Vi har for eksempel hjulpet firmaet Brainreader, som analyserer billeder af hjernen. Før tog det 3-4 timer, før algoritmen var færdig, men efter at have flyttet opgaven til et grafikkort, der sidder i en lille server, tager det nu 2-3 minutter. Så kan patienten få svar undervejs i en konsultation,« fortæller han til Version2.

Siden grafikkort omkring årtusindskiftet blev programmerbare, har Jesper Mosegaard arbejdet med at udnytte kræfterne på en grafikchip (GPU), men selvom der er sket mange fremskridt siden dengang, anser han ikke værktøjerne til formålet for at være helt gode nok endnu.

»Software-API'er og programmeringssprog til GPU-udvikling er ved at være moden, men er altså ikke helt moden. Og så skal man tænke lidt anderledes, end når man programmerer til en CPU,« forklarer han.

På en CPU kan hver kerne udføre én opgave ad gangen, mens en GPU er ’massivt parallel’ og kan udføre tusindvis af beregninger på én gang. Man kan derfor ikke bruge samme fremgangsmåde, hvis man vil have adgang til de mange kræfter på grafikkortet.

»Hukommelsesstyring bliver meget vigtigt, og man skal forholde sig til, at nogle beregninger bliver udført flere gange samtidigt. Med en CPU er vi vant til, at man skriver et program og så regner med, at det er o.k. hurtigt. På en GPU skal man tænke sig mere om, og man bliver straffet mere, hvis man laver fejl, end på en CPU. Det er man nødt til at forholde sig til, ud over at man også skal lære et nyt programmeringssprog,« siger Jesper Mosegaard.

Valgfrihed eller modenhed

De to mest udbredte værktøjer til at programmere til grafikkort er Cuda fra Nvidia og OpenCL, som i princippet kan bruges med grafikkort fra alle producenterne. Af de to muligheder er Cuda det klart mest gennemarbejdede, men omvendt betyder bindingen til Nvidia også, at man skal til at stille krav om Nvidia-hardware hos brugeren.

»Nvidia har smidt mange kræfter efter Cuda gennem årene, og det er blevet meget modent nu. Men det virker jo så kun på Nvidias produkter,« siger Jesper Mosegaard.

Med OpenCL får man mange muligheder, for tanken er, at man kan kode én gang, og så kompilere til forskellige platforme, både forskellige slags grafikkort og CPU’er med flere kerner.

»Hver producent af hardware skal så levere deres egen compiler til OpenCL. Og vores erfaring er, at der er nogle vanskeligheder ved det,« siger han.

Det er heller ikke alle opgaver, som giver mening at flytte til en GPU, ligesom det rent praktisk kan være en dårlig vej at gå, hvis målet er en løsning, der kan bruges af mange forskellige brugere.

»Det er ikke for alle at bruge grafikkortet. Man skal kende sin målgruppe, og man skal vide, hvad de har af hardware,« siger Jesper Mosegaard.

Til gengæld kan computere måske i fremtiden blive så smarte, at en beregningsopgave automatisk kan blive sendt til den chip, der bedst kan løse opgaven, uden at man som udvikler skal kode til det ene eller andet. Det kalder man heterogen computing.

»Der er så småt ved at ske noget i den retning. Og både AMD og Nvidia leverer i dag produkter, hvor CPU og GPU kommer tættere på hinanden og deler hukommelse. Men jeg tror aldrig, at de vokser sammen og bliver til én chip, for det er de for forskellige til,« siger han.

Jesper Mosegaard holder oplæg om programmering til grafikchippen på Goto-konferencen i Aarhus den 1.-3. oktober. Version2 er mediepartner for konferencen.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (10)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Stefan Sommer

Valget af programmeringssprog er mindre afgørende end kendskabet til hardwaren specielt hukommelsessystemet. Der skal i store træk kun par defines eller søg-og-erstat til at skifte mellem OpenCL og CUDA kode - strukturerne er præcist ens, og nødvendigheden af at forstå hardwaren den samme (det er så også det der kan gøre grafikkortprogrammering virkeligt sjovt). De mange python/java/.net til CUDA/OpenCL oversættere kan måske gøre livet en smule nemmere ved at fjerne noget initialiseringskode, men ikke mere.

Henrik Mikael Kristensen

Hvilket er lidt underligt, for Chip RAM var ikke nogen speciel fordel. Fast RAM var det man skulle have, så CPU'en kunne arbejde i fred med data, mens Agnus eller Alice blittede ting rundt på skærmen og Paula spillede lyd fra Chip RAM. Min gamle Amiga 1200 blev omkring 8 gange hurtigere, da den fik 8 MB Fast RAM på 68030 acceleratorkortet, da jeg startede med at køre den kun med 2 MB Chip RAM'en i maskinen.

Hvilke tricks man så brugte til at flytte data mellem Chip og Fast RAM, kan jeg ikke rigtigt huske...

Jan Mortensen

og AMP hvis man sværger til C++

En oversigt http://blogs.msdn.com/b/vcblog/archive/2012/08/14/10339695.aspx

AMP; Keynote fra AMD konference http://channel9.msdn.com/posts/AFDS-Keynote-Herb-Sutter-Heterogeneous-Co...
25:00 En stump kode
27:00 en kølig demo

en mere philosofisk snak … hent slides til denne da man næsten ikke kan læse skærmen
http://channel9.msdn.com/posts/Daniel-Moth-Blazing-fast-code-using-GPUs-...

Michael Nielsen

Det er efterhånden 7 år siden jeg skrev speciale, hvor jeg brugte en GPU (geforce 6800 ultra!) til at foretage beregninger på min geometri. Det overrasker lidt at der ikke er sket mere på så lang tid, det er dælme lang tid for en teknologi at være "bobler" i...

Log ind eller Opret konto for at kommentere