Sådan sætter Java 7 multi-kernerne i sving

ParallelArray er et af elementerne i fork-join-paradigmet, som skal gøre det væsentligt nemmere at skabe parallelle programmer i den kommende Java 7.

Den umiddelbare fremtid byder på pc'er med masser af processor-kerner, og ifølge hardware-folket er det ikke bare sølle to-cifrede antal. I kulissen står arkitekturer med hundredevis af kerner, og det bliver en realitet indenfor de næste ti år.

For at kunne udnytte processorkraften skal programmerne i fremtiden fordele opgaverne ligeligt over hele kerne-parken. Det er ikke så nemt med dagens programmeringsteknikker. De fleste gængse programmer er skrevet sekventielt, og det er ikke så nemt at skrive programmer med tråde, låse og monitorer.

Derfor er der behov for teknikker, som sætter programmørerne i stand til at skrive parallelle programmer på en overkommelig facon.

Parallelle paradigmer

Der er en række forskellige modeller i luften, når snakken går på parallel-programmering.

I paradigmet Software Transactional Programming (STM) benytter man transaktioner, som det kendes fra databaser. I STM kan man få en programstump til at blive udført atomisk. Det betyder, at andre programtråde kun kan se variablernes tilstand enten før eller efter, at den atomiske del udføres. Det er implementeret i sproget STM Haskell.

Et anden paradigme er actor-modellen, som anvendes i sprogene Erlang og Scala. 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.

Et tredje paradigme er fork-join, som især forskeren Doug Lea har været talsmand for. I fork-join opdeles en opgave til en række delopgaver, der kan udføres parallelt. Det er fork-delen af processen. I join-trinnet venter programkonstruktionen til alle delopgaverne er udført, og et endeligt resultat findes på grundlag af delresultaterne.

Gris på gaflen
Der har længe været snak om, at fork-join skulle blive en del af den kommende Java 7, og nu synes det sikkert og vist.

Objektet ParallelArray i den foreløbige implementation gør det nemt at anvende fork-join.

De primære operationer, man kan udføre på et ParallelArray, er at udføre en eller anden procedure på elementerne, og at sammenkoge flere elementer til et nyt enkelt element og til at reducere alle elementerne til en enkel værdi som for eksempel en sum.

Fordelen ved at benytte teknikker som ParallelArray er, at kørselsmiljøet selv kan finde ud af at fordele opgaver hensigtsmæssigt, uanset hvor mange eller hvor få tråde og kerner, som systemet har at gøre godt med.

I en artikel på IBM Developerworks går udvikler Brian Goetz fra Sun i dybden med ParallelArray. Den kan findes via linket herunder.

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

Nu skriver man jo sjældent selv navne på parameter, klasser, metoder osv. i Java, det lader man jo editorens autocomplete om.

Så imodsætning til da man sad og kodede C/C++ for 8 år siden, hvor det var en kunst i sig selv at forkorte alle navne på sine variable mest muligt, uden at det gik alt for meget ud over læsbarheden. Så er det jo idag fuldstændig ligegyldigt, da en moderne editor idag jo har auto complete.

  • 0
  • 0
#5 Mark Ruvald Pedersen

1) Så java måden er den eneste rigtig måde i verden at gøre ting på?

Java navngivnings-kotymen sænker blot indlæringskurven; hvilket ikke altid er godt.

2) Har du om screen screen real estate? Gider jeg at spilde mine dyrebære pixels på en 15", på navne?! Nej.

3) strlen: $ echo "System.out.println" | wc -c 19 $ echo "printf" | wc -c 7

4) omg: ArrayList myArr = new ArrayList();

Dobbelt-konfekt; anyone?

  • 0
  • 0
#6 Thomas Jensen

Nej, Java metoden er ikke den eneste rigtige måde at gøre tingene på, slet ikke. Jeg argumenterede bare imod den "gamle" kotume med at alt skal være så kort som muligt, for så skal vi ikke taste så meget. Og der var mit argument, at med dagens editor er det jo i princippet lige meget, da den gør arbejdet for en.

Ang. dit punkt 4, så går den vel mere på syntax end længden af navnet på typen ArrayList, som efter min overbevisning giver mere mening end ArrLst, ArrList, AList..fortsæt selv listen :o)

Men der er jo mange uskrevne regler fra gamle dage, som man stadig render på. F.eks. synes nogen stadig at en linie ikke må være over 80 tegn. Men igen, med de skærmstørrelser og opløsninger der køres med idag, så er det jo fuldstændig lige gyldigt.

Men sådan er der jo så meget :o)

  • 0
  • 0
#7 Dennis Krøger

1a) "Hvilket ikke altid er godt". Ohhhh, ikke ALTID! Ja så må det være skidt.

1b) Indlæringskurven og, vigtigere, overskueligheden. Det er ikke og allesammen der laver fire&forget programmer.

2) Hvis dine linier bliver for lange af en smule typenavne har du andre problemer end real estate.

3) Ja, lad os bruge globale funktioner, det er så dejligt og passer smukt ind i objektorienteret design.

4) Du har ret, lad os smide type safety ud for at spare et par karakterer. Ikke at kunne bruge nedarvning er et ekstra plus.

  • 0
  • 0
#8 Mark Ruvald Pedersen

Jamen, jeg kan da godt se rode op i Dennis' frustationer som java programmør.

Java er som udgangspunkt, idiot-proof: Alt er gjort på forhånd, intet er længere sjovt. -Men ikke nok med det; type navne skal være sigende. Uha, ja, for det er vi blevet fortalt er godt - ligesom at pointere er slemme. <- Ja, for dem som er svage nok.

  • Jeg stoler ikke på et sprog, hvor der ikke findes pointere - (næsten) alt overføres byvalue <-- Det er RAM producenterne vel nok glade for!

  • Ang. ovenstående: Det er muligt at passere som referance, men det står ikke rigtigt i dokumentationen hvornår dette sker. => defensive copying.

  • Jeg vil gerne kunne typecaste et unsigned char-array til min egen struktur.

  • Der ikke er nogen præprocessor. Ingen typedef's, ingen macroer.

  • Der findes ikke engang unsigned datatyper!

  • Og en byte og en char (char, som er i unicode. Hvorfor ikke kalde den for wchar som alle andre her i verden?) gemmes som 4 bytes!

  • Jeg synes C++ er langt mere alsidigt end java - jeg gider sgu ikke at kode objektorienteret for at lave en simpel parser/algoritme.

  • Java (og C#) er dagens standard, pga. hype og buzz-words. Længe leve C og C++.

  • Savner du færdigtlavede programbiblioteker? Prøv Boost; indtil C++0x.

  • Med defensive copying, minder java ærlig talt mere om INTERCAL end C++.

  • 0
  • 0
#9 Thomas Jensen

"- Java (og C#) er dagens standard, pga. hype og buzz-words. Længe leve C og C++."

Tja, jeg ville da være svært ked af at skulle udvikle mine webbaserede systemer ved hjælp af C/C++ og CGI scripts, men det er måske bare mig :o) På det område er C/C++ vist ikke "fulgt med tiden" (så vidt jeg ved).

Som udgangspunkt overføres alle objekter "by reference" og ikke "by value" i Java.

Pointere savner jeg ikke lige frem og man kan nu sagtens kode "ikke objektorienteret" i Java, hvis det er det man vil.

En præprocessor...hvad skal jeg lige med den? (dette er et spørgsmål :o))

Måske er det bare fordi det er mange år siden jeg sidst har kodet noget i C/C++, men jeg savner rent faktisk intet af det du har nævnt. Men sådan er vi jo heldigvis så forskellige :o)

  • 0
  • 0
#10 Mark Ruvald Pedersen

Jeg kommer heldigvis aldrig til at udvikle noget webbaseret. ... og GUI design, det kan vi få en Abe til at gøre.

Alligevel står der i de (dårlige?) java bøger jeg har læst, at alt passeres byval.

Men defensive copying, må du vel give mig ret i er irriterende? Det er lige noget ekstra unødigt tekst som skal skrives.

For én som mig, som kommer fra elektroniksiden, savner jeg pointere og ægte datatyper.

Præprocessor: Du kan jo bare lade være med at bruge den - jeg er sikker på mange andre savner en til java.

Til embedded design og firmware er der ikke meget som slår ren C.

C er koncis og verbose: Man kan se hvad der sker - det gør man ik med java.

Desuden frådser java med ram.

"Write once, run everywhere" holder ikke helt. C har dog "write once, compile everywhere" og holder hele vejen.

  • 0
  • 0
#11 Thomas Jensen

"Alligevel står der i de (dårlige?) java bøger jeg har læst, at alt passeres byval."

Det gør det i princippet også, men når man snakker objekter, så er det altså ikke en kopi af objektet der bliver sendt med, men værdien af referencen og der af "by-value".

  • 0
  • 0
#12 Joakim Recht

Så meget for en saglig diskussion om de nye features i java7.

Men jeg vil da lige sige tak til Mark for de usandsynligt underholdende indlæg. Jeg vil gerne have lov til at udnævne Mark til IT-Dolph for sine utallige udtalelser om hvor dårligt et sprog Java er. Det er svært at vide om man skal føle sig stolt af at lave GUI-abe-arbejde, men jeg vælger at tage det som noget positivt.

På den mere seriøse side, så bliver det da lækkert at have en feature som ParallelArray indbygget. java.util.concurrent gav et gevaldigt løft i java5, og PA lægger et niveau mere på, så man slet ikke behøver at tænke på at fordele arbejde ud over flere tråde.

  • 0
  • 0
#13 Mark Ruvald Pedersen

Så Joakim, er du måske en autoritet til udnævelse af pinlige titler for folk som ikke er enig med dig?

Og GUI er jo ikke svært - consider it done.

... og hvis du lægger mærke til det, mente jeg oprigtigt i starten at denne nye feature er et skridt i den rigtige multi-core retning.

  • 0
  • 0
#14 Carsten Sonne

[quote] - Java (og C#) er dagens standard, pga. hype og buzz-words. Længe leve C og C++. [/quose]

Det vil jeg blot sige jeg er meget uenig i. Hver sig sprog og framework har sine stærke sider.

En ting er sikkert, i den vestlige verden er det penge og økonimi der driver tingene. Det er uden tvivl også gruden til at så mange har taget C# og Java til sig. Det er simpelhen en økonomisk gevint for virksomheder at bruge disse udviklingsplatforme. Det er ikke hype og Buzz-words. Hvorfor det så er en økonimosk gevinst at bruge disse sprog er et helt andet emne.

Overstående citat vil jeg personligt klassificerer som en religiøs holding, er derved ikke særlig fagligt velbegrundet.

Mvh Carsten Sonne Larsen

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