Jag och ett par kollegor hade förra veckan glädjen att få besöka Scandinavian Developer Conference, en bred utvecklarkonferens i Göteborg. Om man ska summera mina viktigaste intryck från därifrån så passar rubriken ganska bra.
Frasen myntades av Herb Sutter 2005 och syftade till att även om Moore’s lag fortfarande gäller, så realiseras den ökade CPU-kapaciteten numer genom att man kan exekvera fler trådar parallellt i flera kärnor, ”multicore”. Problemet med detta är att det ställs lite nya krav på oss utvecklare och våra program – det är inte längre självklart att nyare hårdvara ökar programmens prestanda. (Eller att vi kan lägga till oändligt många nya features utan slöa ner programmen.) Det här är ju inget nytt under solen, men jag hade själv inte engagerat mig djupare i problematiken tidigare. Nu under konferensen slumpade det sig att blev det något av en röd tråd för mig.
Under sin inledande keynote satte Michael Feathers problematiken i ett sammanhang. Han menar att vi befinner oss i något av en “Design Winter” inom mjukvaruutveckling.På senare år har fokus på det som pratas och skrivs kring mjukvaruutveckling legat mycket på processer. Fokuset på agila processer har fått många att glömma bort gamla kunskaper som fortfarande är lika relevanta. Det kommer inte mycket nya böcker inom ämnet Software Design, de Viktiga Böckerna i ämnet är rätt gamla och diskussioner i ämnet är också relativt ovanliga numera.
Feathers menar nu att vi utvecklare kommer tvingas att ägna oss mer åt design framöver. När våra program i större utsträckning börjar köras på flera kärnor kommer fler hårdvaruabstraktioner att läcka in till mjukvaran och vi kommer bli tvungna att designa våra program så att de i större utsträckning kan exekveras parallellt på flera kärnor.
Problemet
Angelica Langer zoomade sen in på problematiken under en rätt teknisk föreläsning i ämnet ”Java Programming in a Multicore World”. Hon belyste två viktiga konsekvenser av att våra program börjar köras på multicorearkitekturer; den ena handlar om hur vi som applikationsprogrammerare måste jobba mer aktivt för att öka throughput i våra program, den andra handlar om att tillförlitligheten i våra program riskeras.
Throughput-aspekten är förmodligen den som är mest allmänt känd.
Amdahls lag, ger till exempel att om ett program är tvunget att exekveras sekventiellt under 50% av exekveringstiden så spelar det ingen roll hur många processorkärnor vi använder, vi kan aldrig åstadkomma mer än en halvering av exekveringstiden. De 50% av tiden som måste köras seriellt kan nämligen fortfarande bara exekveras i en processorkärna. För att komma runt detta ges tre typlösningar:
- lock-free programming,
- transactional memory och att
- helt enkelt undvika synkroniserade block
Förutom prestandaaspekten, förklarade hon ett annat läskigt faktum. Program som kan ha betett sig helt korrekt single-core kan komma att uppvisa felaktiga beteenden när de börjar köras på flera processorkärnor. Detta beroende på att kärnorna har lokalt minne (cachar, register) som inte garanterat är synkat med ”huvudminnet”. För att komma till rätta med detta måste vi utvecklare lära oss använda (den idag rätt obskyra) modifieraren
volatile korrekt.
Lösningen
Jonas Bonér tar vid och presenterar ett förslag ett annat förslag på lösning. Jonas menar att det i Java är svårt nog för genier att skriva korrekt concurrent kod (för icke triviala problem). För vanliga dödliga är det nära nog omöjligt. Vi som javautvecklare behöver en ny högre abstraktionsnivå för att vi ska kunna jobba på ett vettigt sätt (leverera affärsnytta istället, kanske?). Han mernar att de abstraktioner vi har att jobba med i plain Java är på en för låg nivå för de vanligast problemen vi behöver lösa. Enter Actors.
Actors är ett rätt gammalt påfund, snart 40 år, som främst populariserats av Erlang. Det finns en hög med olika implementationer av Actors för Java och andra JVM-språk. Jonas puffar naturligtvis för sin egen implementation Akka, som har både ett Java- och ett Scala-API. Jag ska inte ens försöka förklara djupare här vad det handlar om, men förenklat handlar det om objekt som inte delar något state med någon annan. De kan enbart interagera med andra Actors genom att skicka meddelanden. Meddelanden skickas asynkront, non-blocking på ”fire-and-forget” manér. Varje Actor har en ordnad meddelandekö, en ”mailbox”, som triggas när någon annan Actor skickar ett meddelande. Det hela påminner en del om ”vanlig” messaging i Java, och det finns även stöd för att integrera Actors som endpoints med Apache Camel.
Scandinavian Developer Conference som helhet var riktigt bra. Det fanns en del att slipa på, främst vad gäller informationsflödet under den pågående konferensen, men i stort sett är jag imponerad över hur bra allt var ordnat redan under konferensens andra levnadsår. Nästa år är tydligen ambitionen att utöka evenemanget till en hel IT-vecka i Göteborg. När får vi se något liknande på hemmaplan i Stockholm?
