Dansker leder efter parallelprogrammeringens hellige Erlang-gral

Softwarefirmaet Triforks tekniske direktør er på jagt efter parallelprogrammeringens hellige gral. Gralen med navnet Erjang håber han at finde ved at skabe en udgave af sproget Erlang til Java-platformen.

Sproget Erlang, der passer som fod i hose til nutidens multikerne-computere, har fået sig en tvilling i Java-lejren.

Erjang, som Java-udgaven er døbt, er udviklet af teknisk direktør i softwarefirmaet Trifork, Kresten Krab Thorup. Siden midten af oktober har han arbejdet med implementeringen af Erjang, og selve sproget er nu på plads, samt en fjerdedel af Erlangs standardbibliotek OTP.

Det er ikke første gang Kresten Krab Thorup kaster sig ud i sprog-implementering. Det har været hans dont lige fra ph.d-tiden på datalogistudiet og i en tidligere udenlandsk karriere. Han står blandt andet bag GNU-compilerens udgave af Objective C, og det var lang tid før sproget fik et mainstream-comeback i form af iPhone-udvikling.

»Der har været meget snak de sidste par år om, at computere ikke bliver hurtigere. Man er rendt ind i en mur med, hvor hurtige CPU'erne kan blive. Man bliver nød til at putte flere cores i CPU'erne for at få mere regnekraft,« konstaterer Kresten Krab Thorup.

Her kan Erlang noget, som andre programmeringssprog har svært ved. Men der er mere endnu, som de siger i TV-shoppen:

»Vi skaber jo flere og flere systemer, som bygger på netværkstjenester, SOA-løsninger og så videre. Der har Erlang en 20 år lang tradition for at skabe systemer, der passer ind i den slags problemer.«

Erlang har erfaring

Det skyldes, at Erlang er anvendt i forbindelse med telefonisystemer i mange år. Sproget er opfundet i det svenske teleselskab Ericsson under ledelse af engelske Joe Armstrong, og sproget er dels opkaldt efter Agner Krarup Erlang, den danske matematiker bag kø-teorien, en statistisk teori til beskrivelse af trafiksystemer så som telefoni, dels som en forkortelse af Ericsson Language.

»Derfor synes jeg at det er vældig spændende at grave mig ned i Erlang og forstå, hvilke problemer, de har løst og hvordan, og for at lære de mønstre, som de har udviklet.«

Kresten Krab Thorup er kommet frem til, at der er to tilgange til parallelisme. På den ene side er der funktionelle sprog og frameworks som Googles map-reduce, hvor man abstraherer paralleliteten væk og skriver programmer på deklarativ vis, og så lader man programmeringssproget eller runtimesystem tage sig af det hårde arbejde.

På den anden side er der systemer, hvor man er nødt til at modellere og forstå samtidighedsproblemer. Det er f.eks. interaktive systemer, som interagerer med tilstande i verden uden for programmet. Her er det funktionelle paradigme ikke så nemt og intuitivt at anvende.

På jagt efter hellig gral

Det er actor-modellen, der gør Erlang til noget specielt. Her er hver enkelt objekt en lille selvkørende maskine med sin egen indre tråd. Objekterne kommunikerer ved at sende meddelelser, men uden at der deles hukommelse på tværs af objekterne. Andre sprog, som f.eks. Scala, kan også byde på actors, men kun Erlang-miljøet har 20 års praktisk erfaring med modellen, betoner Kresten Krab Thorup.

»Jeg er knageme på jagt efter den hellige gral her. Vi skal bruge vores intuition om processer - det er det, jeg gerne vil lære.«

Og Erlang-folket har en slags magisk evne til at forstå parallelle systemer, mener han.

Drømmen er, måske at kunne nedfælde de mønstre, der findes i den parallelle måde i bogform, og skrive en pendent til 90'ernes objekt-bibel "Design Patterns."

Parallelisme er det nye objektorientering

Nogle stemmer siger, at parallelismeproblematikken er overdrevet og kun har betydning for få programmører, f.eks. dem, der skriver servercontainere og biblioteker, mens resten blot kan læne sig tilbage og udnytte mulighederne.

Men Kresten Krab Thorup sammenligner med situationen, da objektorientering blev mainstream for 15 år siden. I starten kunne der være god idé i at holde sig til eksisterende procedurale teknikker, men efter at området var forstået, gav det alle programmører bedre teknikker.

Med Erlang på Java-platformen bliver teknikkerne mere tilgængelige for programmører i firmaer, som har en politik om at benytte Java-baserede platforme såsom JEE-servere.

Kresten Krab Thorup holder to gå-hjem-møder den 12. og 13. januar i henholdvist Tåstrup ved København og Århus. Der er gratis entre, og tilmelding sker på Triforks eller Jaoo's hjemmeside. Der er flere oplysninger om Erjang på projektets hjemmeside, som kan findes via fanebladet "Eksterne links" herunder.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (18)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Torben Rahbek Koch

Nej, Erlang er ikke funktionelt, som F# (hovedsageligt) er. Erlang kan nok bedre sammenlignes med multi-agent-systemer.

Ideen med Erlang er at "objekter" er enkeltstående processer og at "metodekald" på andre objekter laves asynkront via en i Erlang indbygget messaging-mekaniske.

Tør ikke lige sige, om Erlang også har synkrone "metodekald", men det er der sikkert andre, der kan svare på ;-)

  • 0
  • 0
#6 Torben Hoffmann

At Erlang med tiden er blevet udstyret med funktionelle aspekter er dejligt, men det vigtigste ved sproget i det daglige er processerne og måden man håndterer fejl på.

Processerne kommunikerer ved hjælp af "asynchronous message passing", men dette udelukker ikke synkronisering - komponenterne i OTP frameworket giver både en asynkron såvel som en synkron udgave af de fleste af deres API-funktioner. I rå Erlang (uden OTP) skal man selv lave den slags møstre, hvilket er nemt nok, men når man kan OTP bruger man OTP til 95% af ens arbejde.

Erlang har en fail-fast filosofi, hvilket betyder at en proces som ikke kan finde ud af hvad den skal gøre hurtigtst muligt lægger sig til at dø. Tanken er så at en anden proces skal opfange døden og gøre det rette ved problemet, f.eks., genstarte processen. Dette gør at man kan programmere utroligt aggressivt med stort fokus på at levere værdi for kunden og lade en mindre del af koden håndtere fejl. Lidt i stil med det aspect oriented programming gør - bare på et enkelt område i stedet for som en generel struktureringsmekanisme.

Alle processerne har i øvrigt deres egen hukommelse og sammen med message passing så er dette ideelt til multi-core. Dette var dog ment til distribuerede systemer, men virker forbavsende godt til multi-core - man skal bare starte ens Erlang fortolker med et flag og så udnytter den multiple cores.

Rock'n'roll Erlang! Torben

  • 0
  • 0
#9 Kresten Krab Thorup

Jeg forestiller mig ikke, at vi skal have alle folk til at programmere Erlang - endsige Erjang. Erlang er på mange måder at sammenligne med en veteranbil, måske nok en Ferrari, men en veteran bil.

Min pointe er derimod, at der er meget at lære fra Erlang som er af almen interesse. Der er mange års tradition og kultur omkring Erlang, om hvordan man programmerer med parallelitet, og hvordan man laver pålidelige systemer. Og jeg tror at dén måde Erlang-folk gør det på er temmelig kompatibel med den objekt-orienterede tankegang.

Du kommer ikke til at lave væsentligt bedre programmer, bare fordi du begynder at skrive dem i Scala. Der skal mere til. Du skal have de patterns - om du vil - der skal gøre programmerne bedre - den rigtige måde at tænke på. Det kommer ikke bare fordi du får 7 nye sprog features.

SÅ, ... Erjang er ikke den hellige gral. Slet ikke. At lave Erjang er min måde at grave mig ned i denne kultur på. Og det er de oplevelser jeg gør mig på vejen som jeg gerne vil fortælle om. Det skriver jeg mere om på min blog http://javalimit.com.

  • 0
  • 0
#10 NA NA

Du kommer ikke til at lave væsentligt bedre programmer, bare fordi du begynder at skrive dem i Scala. Der skal mere til. Du skal have de patterns - om du vil - der skal gøre programmerne bedre - den rigtige måde at tænke på. Det kommer ikke bare fordi du får 7 nye sprog features.

Nej det er jeg sådan set enig i men det samme gælder vel for Erlang ?

Jeg forstår stadigvæk ikke hvad man skal bruge Erlang til Java til hvis jeg har forstået dig ret og der ikke er nogle konkrete sprog features du mangler i Scala (jeg kender ikke selv Erlang godt nok til at vide det.

  • 0
  • 0
#11 Kresten Krab Thorup

Problemet er, at eksisterende Java frameworks ofte ikke er egnede til at køre i mange tråde / super-parallelt. Der skal en anden diciplin til, som jo gennemtvinges af fx Erlang eller Clojure.

At kalde java-kode fra Erjang er ganske simpelt, men ikke tilrådeligt. Man kan tilføje en java-annotation på sin static public funktion, og så kan den kaldes direkte fra Erjang. Det er den måde jeg implementerer Erlangs built-in-functions. Men det skal gøres med omhu, ligesom du idag skal være omhyggelig når du kalder native funktioner fra Java.

  • 0
  • 0
#12 NA NA

Der skal en anden diciplin til, som jo gennemtvinges af fx Erlang eller Clojure.

Så hvis jeg har forstået dig ret så er det ikke godt nok at Scala har en Actor model man skal tviges til altid at følge Actor modellen ?

  • 0
  • 0
#13 Kresten Krab Thorup

Så hvis jeg har forstået dig ret så er det ikke godt nok at Scala har en Actor model man skal tviges til altid at følge Actor modellen ?

Ja, jeg mener at programmere med eller uden actors er lige så fundamentalt som at programmere med eller uden garbage collection. Man kan godt blande kode der bruger malloc/free med kode der bruger garbage collection, men det er alt for nemt (og fristende) at lave fejl der ødelægger de fundamentale fordele ved garbage collection.

Tilsvarende med actors. Hvis man skal programmere effektivt med actors i Scala skal man forstå faldgruberne i den parallelitet der introduceres, og holde en streng diciplin. Det kan godt lade sig gøre, men i et større system tror jeg at det er svært at overskue om man har gjort det rigtigt. Og det er fristende at lade være, fx fordi man har noget gammel kode der lige skal genbruges.

Derfor tror jeg at det er en stor fordel - hvis man skal programmere med actors - at programmere i et sprog der tvinger dig til at følge reglerne. Ja.

  • 0
  • 0
#14 Kresten Krab Thorup

Jeg forstår stadigvæk ikke hvad man skal bruge Erlang til Java til hvis jeg har forstået dig ret og der ikke er nogle konkrete sprog features du mangler i Scala (jeg kender ikke selv Erlang godt nok til at vide det.

Nu er det slet ikke min mening at nedgøre Scala, jeg synes at det er et fint sprog som gør mange ting rigtigt. Men så vidt som jeg er kommet i mine erkendelser om actors er der et par fundamentale ting jeg synes der mangler i Scala i forhold til at udnytte de ting som jeg synes Erlang gør rigtigt.

  1. Der er ikke rigtige letvægtstråde. Som Joe Armstrong siger, "forestil dig et objekt-orienteret programmeringssprog, hvor man kun kan lave 1000 objekter" - det vil give dig et forkvaklet forhold til objekter, ikke? Tilsvarende med processer - hvis de er super billige kan man bruge dem anderledes naturligt.

  2. For at programmere naturligt med letvægtstråde skal man kunne lave "blokerende operationer" midt i koden, uden at det betyder at man holder OS-resourcer. Når man programmerer i Scala skal man sørge for at dine actor operationer terminerer hurtigt for ikke at "holde på en tråd".

  3. Som diskuteret ovenfor "mangler" scala en mekanisme til at gennemtvinge at processer ikke deler mutérbare tilstandsvariable. Det kræver diciplin at holde sig på den smalle sti.

  4. Erlang har (som flere andre actorsprog) det der hedder "selective receive", som er en måde at være selektiv i hvilke beskeder man vil agere på hvornår. Det er fundamentalt set den mekanisme man bruger i Erlang til at håndtere flere samtidige "samtaler" med andre actors. Hvis man skal klare sig uden selective receive bliver din kode væsentligt mere kompliceret, hvis interaktionerne bliver en smule mere komplicerede.

Så ja, jeg tror at det vil være en stor fordel at have et sprog der understøtter at man tænker naturligt i actors uden at skulle "bekymre" sig om alle disse forskellige problemstillinger på en lavere abstraktionsniveau. Men det er da sagtens muligt. Og scala er helt sikkert et stort skridt frem fra Java på mange måder. Jeg er bare ved at se på hvad det næste skridt så skal være :-)

  • 0
  • 0
#15 Torben Hoffmann

Hej Kresten,

SÅ, ... Erjang er ikke den hellige gral. Slet ikke. At lave Erjang er min måde at grave mig ned i denne kultur på.

Hvorfor ikke forstå denne kultur ved at lave et (del)system i Erlang? Det kan selvfølgelig være, at du forstår en tankegang bedst ved at implementere den selv, men for mig virker det som unødig smerte at påføre sig selv ;-)

Desuden har flere folk haft succes med at bruge Erlang som backbone og så lave noget UI i Java, Ruby et al.

Jeg har arbejdet kommercielt i 2½ år med Erlang og senest lavet et kursus i basal Erlang. På baggrund af dette vil jeg anbefale langt de fleste at købe "Erlang Programming" og lave nogle programmer selv for at lære den specielle Erlang kultur.

Skulle du eller andre have lyst til at høre lidt "krigshistorier" stiller jeg gerne op til det.

  • 0
  • 0
#16 NA NA
  1. Erlang har (som flere andre actorsprog) det der hedder "selective receive", som er en måde at være selektiv i hvilke beskeder man vil agere på hvornår. Det er fundamentalt set den mekanisme man bruger i Erlang til at håndtere flere samtidige "samtaler" med andre actors. Hvis man skal klare sig uden selective receive bliver din kode væsentligt mere kompliceret, hvis interaktionerne bliver en smule mere komplicerede.

Gør Erlang ikke det med pattern matching ret meget på samme måde som Scala ?

Man kan eksempelvis skrive:

[code=java] class Customer(val id: Int) extends Actor { var shorn = false

def act() = { loop { react { case Haircut => { shorn = true println("

 customer " + id + " cut")  
        }  
      }  
    }  
  }  
}  
[/code]
  • 0
  • 0
#17 Jon Loldrup

Du nævner at Erjang har den egenskab at det tvinger programmøren til ikke at dele muterbart lager mellem to processer. Ved du om Google Go har den samme egenskab, eller, om Google Go i den forstand falder i samme fælde som Scala? Altså, at man nok tilbyder en model for concurrent programmering, men ikke fastholder at man så også skal følge den model for programmering til dørs (ved f.eks. ikke at kunne dele muterbart lager mellem processer)?

  • 0
  • 0
#18 Jesper Louis Andersen

Go beskytter ikke data for dig på samme måde. Det forventes at programmøren ikke deler state mellem to eller flere "goroutines". Du kan i princippet sende en pointer til en datastruktur over en kanal, men da er det op til programmøren at sikre sig disse data har et passende ejerskab.

I Erlangs C-runtimesystem med default garbage collection har hver erlang-process sin egen GC. Det betyder at message passing foregår ved copying (visse data dog undtaget). Derfor er det dårlig Erlang-stil at sende et 8 megabyte stort binært træ fra en process til en anden. I stedet pakker du træet ind i process og sender det messages når du vil lave operationer på det (hvis det altså skal deles mellem flere forskellige proces'er).

Jeg formoder at Erjang er anderledes her fordi JVM kun har een heap som garbage collectes (btw, det er en af de fedeste garbage collectors der eksisterer).

  • 0
  • 0
Log ind eller Opret konto for at kommentere