Anledningen for dette besøket til Edinburgh var, som nevnt, et MPI-kurs i regi av PRACE (Partnership for Advanced Computing in Europa) og arrangert av EPCC (tidligere en forkortelse for Edinburgh Parallel Computing Centre, nå bare et navn). Kurset var som vanlig bra saker (folkene på EPCC kan sine saker), og selv om jeg har syslet litt med MPI før synes jeg at jeg fikk veldig mye ut av et kurs på bare tre dager. Jeg vil egentlig si at det var en fordel å ha litt erfaring fra før, siden jeg kunne benytte anledningen til å spørre om mer avanserte ting enn bare det helt grunnleggende.

MPI, som står for Message Passing Interface, er for tiden den fullstendig dominerende standarden for kommunikasjonsmodellen som kalles Message Passing. Message Passing skiller seg fra for eksempel delt-minne, der flere tråder kan modifisere det samme minnet, ved at man må eksplisitt sende og motta beskjeder for å kummunisere mellom prosesser. MPI brukes gjerne, men ikke nødvendigvis, med programmeringsmodellen som heter SPMD (Single Program Multiple Data), som går ut på at man starter flere kopier av samme kjørbare program, og det eneste som i utgangspunktet skiller dem er at de får hver sin unike ID tildelt fra MPI-biblioteket. Ved å kjøre tester på denne IDen kan man så sørge for at hver kopi oppfører seg forskjellig, og man ender gjerne opp med at hvert program gjør omtrent de samme operasjonene på forskjellige data.

Denne måten å programmere på er veldig godt egnet i naturvitenskap. Hvis man for eksempel skal simulere havstrømmer vil man typisk dele opp problemet så hver prosess simulerer en mindre del av området man er interessert i. De fysiske lovene som beskriver bevegelsene er de samme over alt, mens ting som kystlinjer, temperatur og strøm kan være forskjellige.

Jeg vet ikke om det faktisk er slik, men jeg føler at de mest grunnleggende MPI-funksjonene ligger på et noe lavere nivå enn der jeg vanligvis befinner meg. (Og med lavere nivå mener jeg ikke mindre imponerende eller noe slik, men nærmere maskinens grunnleddende funksjonalitet. Rett på jernet, sier man gjerne om lavnivå greier, skjønt MPI ligger et stykke over det.)

Grunnen til at jeg føler det er at man må passe litt på hva man driver med, hvis ikke bare henger hele programmet. For eksempel, hvis man kaller MPI_SSEND for å sende en beskjed er det som å stille seg opp med en brev i hånden, og vente til noen kommer og tar det. Kommer det ingen å henter det blir du bare stående. Som foreleseren sa, i en av mange gode analogier, «if you send someone an email it doesn't magically appear in their brain». Mottakeren må aktivt motta. Å aktivt motta vil si å kalle MPI_RECV, som er som å stille seg opp med hånden frem og vente på at noen skal komme å gi deg et brev, og om det ikke kommer noe brev blir man bare stående.

For å gjøre det hele litt smidigere finnes det såkalte non-blocking funksjonskall, men det kommer igjen med sine utfordringer. For eksempel, si at du vil sende en variabel, og så regne litt mens du venter på at noen skal ta imot sendingen. Du kaller MPI_ISSEND, som er som å legge et brev i utboksen din, så mottakeren kan komme og hente det når det passer. Men så regner du litt videre, og kanskje overskriver du variabelen du sendte. I såfall er det ikke godt å si hva mottakeren endte opp med, for du vet ikke når beskjeden faktisk ble sendt. Hvis du er riktig heldig og det var mye data kan mottageren tilogmed ha endt opp med en delvis overskrevet versjon av det du prøvde å sende.

De to situasjonene jeg beskrev over kalles gjene synkron og asynkron kommunikasjon, i rekken av god analogier beskrevet som forskjellen på å ringe og å sende brev. Ringer du noen står du der og venter til de tar telefonen, og først da skjer kommunikasjonen. Sender du et brev vet du ikke noen annet enn at brevet er sendt, og alt du kan gjøre er å håpe på at det blir lest på et senere tidspunkt. Og det at man må tenke på slik ting som synkron eller asynkron (og bufret eller ubufret) kommunikasjon er det som gjør at jeg føler at dette er lavnivå greier. Men det sier antagelig mest om min beskyttede oppvekst. Uansett, parallellprogrammering er gøy, både som intellektuell utfordring og fordi det kan få ting gjort i en fei. Anbefales på det sterkeste.