Få de daglige nyheder fra Version2 og Ingeniøren. Læs mere om nyhedsbrevene her.

close
Ved at tilmelde dig accepterer du vores Brugerbetingelser, og du accepterer, at Teknologiens Mediehus og IDA-gruppen lejlighedsvis kan kontakte dig om arrangementer, analyser, nyheder, job og tilbud m.m. via telefon og e-mail. I nyhedsbreve, e-mails fra Teknologiens Mediehus kan der forefindes markedsføring fra samarbejdspartnere.
forskningsingeniøren bloghoved

Hukommelsessvigt...

Forleden dag opstod et uventet problem i mine beregninger i Matlab: Der var ikke mere hukommelse tilbage, og mine beregninger stoppede derfor med nedenstående fejlmeddelelse.

At hukommelse på et tidspunkt i løbet af mit ph.d. projekt bliver en udfordring, har været klart hele tiden, men at det skete allerede nu, mens jeg endnu regner på nanofotoniske strukturer, som effektivt er to-dimensionelle (2D), var en smule uventet. I det nye år skal jeg i gang med at udvikle en formalisme og kode, som kan bruges til at analysere realistiske, tre-dimensionelle (3D) problemer, f.eks. lysudbredelse og -udsendelse i fotoniske krystal membraner som den vist på billedet nedenfor. Denne udvidelse, fra effektive 2D til 3D beregninger, vil rent matematisk kun kræve mindre udvidelser, men mht. de numeriske beregninger vil udvidelsen være særdeles krævende, både hvad angår hukommelse og hastighed.

Illustration: Privatfoto

Lysudbredelse i fotonisk krystal membran. Kilde: Nanofotonik Teori og Signalprocessering

Så det kan, i lyset af de hukommelsesproblemer jeg allerede i mine 2D beregninger er stødt på, godt betale sig at tænke både hukommelse og hastighed ganske meget ind i algoritmerne og flowet i den kode, jeg skriver. Herunder:

  • Profiling: Profiling handler om at køre koden på et repræsentativt problem for at få et overblik over, hvilke dele af koden som kaldes ofte, og specielt hvor lang tid hver del af koden tager. Dette kan udgøre et udgangspunkt for, hvor i koden man bør investere sin tid og sine kræfter i at forbedre og optimere.
  • Parallelisering: Parallelisering af de dele af koden, som kan køres uafhængigt, således at flere processer kan køres parallelt frem for sekventielt. Dette kan i Matlab bl.a. gøres ved at erstatte for-løkker med parfor-løkker, som netop udnytter, at beregningerne i hvert skridt af løkken kan laves uafhængigt og dermed parallelt. Jeg er i den forbindelse blevet gjort opmærksom på såkaldt Pinligt Parallelle Problemer, som min egen kode indeholder, og som det derfor er oplagt at parallellisere.
  • Hukommelse: Jeg gemmer pt. meget data i hukommelsen, mens en beregning pågår, og dette har ikke hidtil været et problem. Men som beskrevet ovenfor er dette nu blevet en udfordring, og det er derfor værd at overveje, hvad som kan slettes undervejs i beregningerne, og om der er behov for at gemme data til harddisken. Det sidste har jeg hørt blandede ting om, og min egen oplevelse har været, at det er langsomt at skrive og læse til og fra harddisken. Men hvad gør man som alternativ, hvis man har mere data undervejs i beregningerne, end der kan være i hukommelsen? Beregningerne laves i øvrigt pt. på en computer med 32 GB RAM, hvilket altså ikke var tilstrækkeligt i ovennævnte beregning.
  • Programmeringssprog: Jeg har i årevis skrevet kode og lavet simuleringer og analyser i Matlab. Men som beskrevet tidligere har jeg i dette efterår lært det basale i Python, og jeg har fået anbefalet at lave mine simuleringer i dette sprog frem for i Matlab - bl.a. fordi det er nemmere at skrive effektiv og hurtig kode. Indtil videre satser jeg på at fortsætte i Matlab, men mine erfaringer med Python dette efterår har dog været så positive, at jeg ikke afviser tanken om et skifte.

Så selvom jeg i mit første blogindlæg her på siden lagde op til, at jeg med udgangspunkt i teori og beregninger har færre praktiske udfordringer end folk, som arbejder i renrum og laboratorier, så er jeg bestemt ikke fritaget fra praktiske overvejelser om mit værktøj og mit "laboratorium".

Nu er det tid til at parallelisere, optimere og forbedre kode!

Jakob Rosenkrantz de Lasson er civilingeniør og ph.d. i nanofotonik fra DTU. Jakob arbejder som Product Lead og forskningsingeniør hos virksomheden TICRA i København og blogger om forskning, fotonik og rumteknologi. Jakobs blog har tidligere heddet DTU Indefra (2012-2016) og DTU Studenten (2012)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først

Op imod 32GB i 2D ? Der skal vist noget seriøst optimering til nogensinde at få den simulering over i 3D :-) Ikke at det er umuligt. Hvis det er en indviklet kode skrevet uden hensyn til matlabs måde at håndtere hukommelse er der potentielt meget at hente både i speedup og memory consumption ved at gøre tingene lidt smartere, se her eksempelvis:
http://undocumentedmatlab.com/blog/interna...

  • 0
  • 0

HP ProLiant DL385p - Dual Opteron og op til 768 GB RAM ;-)

Hvis du bruger Python i forvejen så findes der et python-interface til Amazon Web Services, boto, https://github.com/boto/boto .

Med boto kan man skrive et python-script som konfigurerer, spoler instances up på AWS og starter de programmer man gerne vil köre. Når programmet er färdigt kan man hive resultaterne hjem og lukke maskinen igen.

Man kan for eksempel hyre en maskine med 32 kerner og 244 GB ram for 3.5 USD/timen. Med sådan et monster burde en beregning ikke tage lang tid. Man betaler dog for hele timer, så hvis maskinen er for hurtig, koster den på en måde mere end den burde.

http://aws.amazon.com/ec2/pricing/

Ulempen er selvfölgeligt at NSA stjäler ens data. Nogen gange kan man leve med det.

  • 0
  • 0

Op imod 32GB i 2D ? Der skal vist noget seriøst optimering til nogensinde at få den simulering over i 3D :-) Ikke at det er umuligt. Hvis det er en indviklet kode skrevet uden hensyn til matlabs måde at håndtere hukommelse er der potentielt meget at hente både i speedup og memory consumption ved at gøre tingene lidt smartere, se her eksempelvis:
http://undocumentedmatlab.com/blog/interna...

Det skal der i sandhed. Til min kodes (og ikke mit eget!) forsvar skal det siges, at der er nogle lavthængende frugter, som kan bruges til at afhjælpe memory-problemet - hvilket jeg først har tænkt over nu, hvor det i praksis er blevet et problem. Så det skal ordnes som det første.

Derefter kommer den lidt mere systematiske strukturering, og tak for input til den del:-)

  • 0
  • 0

Du kan jo overveje at besøge sektionen for algoritmer, logik og grafer i stuen i 322 (selvom vores spidskompetence ikke er matlab). Jeg vil vædde på at vi kan bidrage med noget :)

  • 0
  • 0

At benytte harddisken som ekstra hukommelse er generelt ENORMT sløvt... en ting jeg dog har lært efterhånden er at ved lange beregninger kan man med fordel gemme en status (som kan genoptages fra) på harddisken... og derudover kan disken bruges til midlertidigt at "sætte ting til side" (f.eks. et eller andet stort array der ikke lige skal bruges til de næste par tusinde beregninger)... den del vil evt. kunne speedes op ved at benytte en SSD til mellemlagringerne...

Så vidt jeg husker, så er Matlab i øvrigt sådan indrettet at den insisterer på at gemme arrays (og dermed også n-dimensionelle matricer) i et stykke fortløbende hukommelse - hvis dit OS derfor har kastet andre processer lidt tilfældigt ind i hukommelsen kan 32 GB ram sagtens være ensbetydende med at du ikke kan få lov at lave en enkelt matrix der er større end måske 4-8 GB (og det vil være forskelligt fra kørsel til kørsel)... ved du/kan du regne ud hvor meget hukommelse du har brug for fra start? at lave en tom matrix af rette størrelse før man benytter den er f.eks. langt hurtigere end at udvidde den løbende...

  • 0
  • 0

At benytte harddisken som ekstra hukommelse er generelt ENORMT sløvt... en ting jeg dog har lært efterhånden er at ved lange beregninger kan man med fordel gemme en status (som kan genoptages fra) på harddisken... og derudover kan disken bruges til midlertidigt at "sætte ting til side" (f.eks. et eller andet stort array der ikke lige skal bruges til de næste par tusinde beregninger)... den del vil evt. kunne speedes op ved at benytte en SSD til mellemlagringerne...

Så vidt jeg husker, så er Matlab i øvrigt sådan indrettet at den insisterer på at gemme arrays (og dermed også n-dimensionelle matricer) i et stykke fortløbende hukommelse - hvis dit OS derfor har kastet andre processer lidt tilfældigt ind i hukommelsen kan 32 GB ram sagtens være ensbetydende med at du ikke kan få lov at lave en enkelt matrix der er større end måske 4-8 GB (og det vil være forskelligt fra kørsel til kørsel)... ved du/kan du regne ud hvor meget hukommelse du har brug for fra start? at lave en tom matrix af rette størrelse før man benytter den er f.eks. langt hurtigere end at udvidde den løbende...

Tak for rådene! Jeg præ-allokerer generelt mine datastrukturer i det omfang det er muligt, så den del af koden burde fungere optimalt.

  • 0
  • 0
Bidrag med din viden – log ind og deltag i debatten