Flere CPU-kerner tvinger udviklere over i funktionelle sprog

7. oktober 2009 kl. 16:2329
JAOO: Flerkerne-problemet vil i det lange løb tvinge programmører til at kode i funktionelle sprog. Sådan lyder spådommen fra Haskell-manden Simon Peyton-Jones.
Artiklen er ældre end 30 dage

Hvis programmer skal skalere over mange cpu-kerner, skal udviklerne bruge funktionelle sprog, eller i hvert fald sprog, med funktionelle elementer.

Så kontant lyder budskabet fra Simon Peyton-Jones, som gav en hovedtale på JAOO-konferencen tirsdag.

I mange år har han arbejdet i Microsofts engelske forskningcenter med det funktionelle sprog Haskell, som mest har at gøre med forskning.

»De funktionelle sprog har altid manglet en killer-app. Funktionelle sprog er bredspektrede og er bare bedre til alting, set fra mit ydmyge, forudindtagede synspunkt. Med hensyn til parallelisme har vi et problem med det konventionelle programmerings-økosystem. Alle ved, vi har et problem. Jeg er sikker på, at mens vi bevæger os længere og længere ind i den parallelle æra, vil vi programmere med endnu færre sideeffekter og endnu mere uforanderlighed (immutability, red.). Om vi kalder det funktionel programmering eller ej, det ved jeg ikke. Men jeg er sikker på, at det bliver retningen.«

Artiklen fortsætter efter annoncen

Funktionelle sprog er ikke endestationen
Men selvom funktionelle sprog har en del af løsningen på problemet med parallelisme, er det for tidligt at bryde ud i klapsalver.

»Jeg tror ikke, at funktionelle sprog har et færdiglavet svar. Samtidighed (concurrency) og parallelisme er et meget kompliceret problem. Bare fordi du skriver i Haskell, betyder det ikke nødvendigvis at du får god lokalisering eller finkornethed i dine beregninger. Du kan nemt skrive parallelle Haskell-programmer, som genererer alt for meget samtidighed og alt for finkornet med en for lille grad af lokalisering.«

Men hvis man skal skrive parallelle programmer er det bedre at starte fra et udgangspunkt, hvor sideeffekter er undtagelsen, snarere end reglen.

Mange synes, at funktionel programmering virker lidt langhåret. Så hvordan kommer man i gang med at programmere funktionelt, hvis man kommer fra Java eller C#?

»En måde er at bevæge sig langsomt i gennem et sprog som Clojure, F# eller Scala, fordi de er .Net- eller JVM-sprog, og på den måde tillader én at gøre alt, som man kunne i forvejen. De tillader en mere gradueret tilgang. Du får ikke gevinsten, hvis du skriver Java i Clojure, men det tilskynder dig til at gå i den rigtige retning. Det er derfor, at jeg er meget begejstret for fremkomsten af sprog som Clojure og F# i den kommercielle verden, fordi de giver denne overgangsmulighed.«

29 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
1
7. oktober 2009 kl. 18:17

Er det ikke ønske tænkning fra Microsoft, eller har det også en relevans på andre styresystemmer.

2
7. oktober 2009 kl. 18:29

Haskell er ikke specifikt for Windows, ligesom mange af de ting, der laves hos Microsoft Research heller ikke er det. Og når Simon nævner Clojure og Scala som veje til Haskell for de spage, så viser han jo også, at han ikke kun tænker i MS produkter.

3
7. oktober 2009 kl. 20:23

Jeg synes da det er en fallit erklæring for vores fag hvis nye cpu arktiekturer kræver nye sprog.

Er "Flerkerne-problemet" ikke noget der bør løses på vm niveau??

12
8. oktober 2009 kl. 10:31

Jeg synes da det er en fallit erklæring for vores fag hvis nye cpu arktiekturer kræver nye sprog.</p>
<p>Er "Flerkerne-problemet" ikke noget der bør løses på vm niveau??

Du kan godt kalde det en falliterklæring, men jeg vil nærmere kalde det en erkendelse af, at ikke alle problemer kan løses af en computer. Specielt er det bevist, at mange spørgsmål om et programs opførsel (f.eks. "kan det her program deadlocke?") er matematisk set uafgørlige, og derfor ikke kan beregnes på en computer.

At lade compiler/VM/hardware selv kan finde ud af at parallelisere vilkårlige programmer, svarer til at lade en computer afgøre sådanne spørgsmål, og er derfor selvsagt uafgørligt.

Det betyder ikke, at compileren aldrig kan parallelisere et program, men det er naivt at regne med, at man kan ignorere problemet, mens man programmerer.

Man kan lave ikke-turingkomplette sprog, hvor mange analyser inklusive parallelisering [i]er[/i] afgørlige, og det vil man nok også i stor udstrækning gøre. Men man kommer nok ikke udenom, at man til mange opgaver bliver nødt til at gøre parallelismen eksplicit i programmet.

13
8. oktober 2009 kl. 12:39

Min oplevelse gennem mange år i branchen er den, at alt for mange såkaldte programmører kun vil lave lækre objekter. De gider ikke SQL, og de gider ikke fatte hvordan maskinen iøvrigt fungerer. Der er ikke mange, som evner at følge et flow gennem et program. Java og objekter er det eneste de kan, og derfor er vi tilbage ved det gamle ord om, at for den der kun har en hammer - ligner alle problemer søm. Ovenstående er per min erfaring den væsentligste årsag til dårlig performance i dagens systemer. Jeg har mødt programmører, som mente at Java var det laveste mulige niveau. Jovel, kan man forestille sig, at man bliver bedre til at køre bil, hvis man ved lidt om, hvordan den fungerer, eller er jeg helt gal på den? Det skal ikke forstås sådan, at jeg synes OOP er skidt, men jeg er enig i, at det ikke egner sig til alt.

14
8. oktober 2009 kl. 13:39

Ærede programmører, autodidakte, softwarearkitekter, systemadministratorer og ledere!

Det er nu ved at være på tide at indse vi, muligvis, står foran et paradigmeskift. I første omgang flere kerner, på sigt ryger cache coherency og shared memory. Det betyder at der skal tænkes i nye baner hvis vi vil blive ved med at kunne udnytte vores hardware optimalt. Det er på tide at man smider de gamle sprogparadigmer, algoritmer og datastrukturer på hylden og begynder at kigge på hvad der sker når tingene er parallelle.

Hvis DU ikke gør noget, så ender du med at sidde et halvfarligt sted i fødekæden.

16
8. oktober 2009 kl. 14:12

@Jesper LA Nemlig! :-)

Det er så øv at folk altid tror at data det skal man gemme i RDBMS (og så køber de samtidigt lige Oracle for det har naboen også). I stedet for at se på deres data og så afgøre hvilken natur de har. BigTable, CouchDB, Lotus Notes, Alfresco ECM mv. har glimrende data lagrings systemer. Er de relationelle? Har jeg brug for transaktioner?

Det samme gælder programmeringsparadigmerne. Behandling af XML (som vi jo nok alligevel beskæftiger os en del med), er altså ikke særlig smart i objektorienterede sprog, og der er desværre alt for mange eksempler på at vores værktøjskasse er alt for lille.

For dem der ikke allerede har læst den, så kom igang "The Pragmatic Programmer".

@Nicolai Du har helt ret, mange udviklere har ikke den nødvendige skoling i hvordan en computer fungerer. (Andrew Tannenbaum har skrevet en god række bøger om emnet, og de er da vist også stadig pensum?).

@Torben Jeg tror jeg fik forklaret mig skidt. Vi er nemlig enige om at ikke alt kan maskin paralleliseres. Men håndtering af locks på tilgang til memory kan i meget stor udstrækning klares maskinelt (nøjagtigt som når man vil foretage en transaktion i RDBMS). Altså STM som det er implementeret i ML.

15
8. oktober 2009 kl. 14:02

Hvis <em>DU</em> ikke gør noget, så ender du med at sidde et halvfarligt sted i fødekæden.

... sammen med Nikolaj B ;-)

17
8. oktober 2009 kl. 14:19

@Kim

Nu ikke personlig... :-) Debatten er da holdt temmelig sober indtil videre.

Måske du har noget konkret at tilbyde debatten, eller vil du bare svine folk til?

18
8. oktober 2009 kl. 15:27

@Nikolaj

Hvis jeg må starte med at 'synge' lidt Poul Krebs

'Det var ikke min mening at sige det, men jeg mente det jeg sagde' ;-)

Efter at have læst denneher, så blev jeg fristet over evne

Lad os nu enes om at få alt det der snavns der kan klares af maskinerne (det er jo altså derfor vi har opfundet dem) lavet af maskinerne. Der er ingen grund til at vi skal bebyrdes med det.</p>
<p>Skal en hardwaremæssig bagatel som ikke har noget med den problemstilling en programmør skal løse at gøre, bestemme hvilket programmeringsparadigme han skal bruge? Næppe.

Jeg skal forsøge ikke at lade det ske igen.

PS. At gøre ting i sekvens - det er at lefle for maskinen!

19
8. oktober 2009 kl. 15:43

@Kim,

Jeg må beklage du ikke forstår teksten

Folkaring (til Kim): Teksten du referere (muligvis lidt dårligt formuleret) forsøger at beskrive nøjagtigt det samme som Jesper Louis. En tekst du så cireterer og implicit siger jeg har sagt det modsatte af???

Så jeg kan kun konkludere at du allerede sidder på den planet der ligger det halvfarlige sted i fødekæden Jesper taler om, og det nok var derfor du var så nem at friste over evne :-) Eller måske er det fordi du hører Poul Krebs det ved jeg ikke? Han er vel også ca. lige så moderne som Algol, så egentlig passer det jo fint.

Du må gerne lade det ske igen, hvis du har noget substans er det endnu bedre du gør det. Så jeg spørger igen har du noget at tilføre debatten andet end personlige tilsvininger?

PS.

PS. At gøre ting i sekvens - det er at lefle for maskinen!

Øhh???

20
8. oktober 2009 kl. 15:51

@Nikolaj

Så nu er du enig med Jesper Louis - LOL

21
8. oktober 2009 kl. 16:01

@Kim

Så nu er du enig med Jesper Louis - LOL

Ja det tror jeg faktisk du kan gå op læse i tråden, hvis altså ikke det er over dine evner?

Jeg stoler ikke helt på dem (dine evner), så jeg tillader mig at bringe citatet her så du kan læse og forstå:

@Jesper LA
Nemlig! :-)</p>
<p>...

Men igen, har du nogle relevant synspunkter til debatten, eller ønsker du bare at fremstå som dømmende overfor andres holdninger der måtte divergere i forhold til dine egne?

Jeg udleder af dine spydigheder, at du er uenig i noget af det jeg har skrevet. Kan du så venligst ikke henlede min opmærksomhed på hvad det konkret er du ikke er enig med mig i? Så kan debatten da tage en saglig drejning, i stedet for det vås du indtil nu har præsteret.

22
8. oktober 2009 kl. 18:19

Ønsker man at prøve kræfter med den nye måde at tænke software på i 'virkeligheden', så kan Erlang være en god vej ind.

En række spændende 'middelware' (i den brede forstand) -produkter er udviklet oven på Erlang og OTP, og til disse er der i stor udstrækning både Client-Lib's og Extension API'er i native Erlang

Blandt disse kan nævnes

RabbitMQ - client/extension Ejabberd - client/extension CouchDB - Erlang native views på vej Yaws - custom handlers Mochiweb - custom handlers

Og der skal nok være flere :-)

23
8. oktober 2009 kl. 19:26

@Kim

Så lykkedes det! :-)

Ja Erlang er ret fantastisk til samtidighed. Men det skinner mest pga. sin fantastiske runtime.

Apache CouchDB er et meget interessant project (men det er igen runtime der er i fokus). Men man skylder sig selv at evaluere HBase inden man gør sit valg. Iøvrigt har jeg svært ved at se CouchDB som middleware (med mindre du mener web server delen af den). CouchDB og HBase vil være fortrindelige basckend implementeringer af CMS systemer.

Har du checket Dynomite http://wiki.github.com/cliffmoon/dynomite

Samtidigt er det vel netop der at view teknologien kan tilgås fra en hvilken som helst anden platform, der gør det vældigt mere interessant, end det er Erlang native views?


Jeg tror iøvrigt du ser mig som en modstander af funktionelle sprog? Det er ikke tilfældet. Jeg synes bare de der følelsesladede argumentation om at mit sprog er bedre end dit fordi... er for åndsvage. De tangerer jo tabs vs. spaces, '{}' diskussinerne. Kvalitet er og bliver en subjektiv størrelse.

Ønsker man at prøve kræfter med den nye måde at tænke software på i 'virkeligheden', så kan Erlang være en god vej ind.

Du er nok nødt til at forklare hvad din brug af nye betyder? Hvori ser du noget nyt?

24
8. oktober 2009 kl. 21:00

Erlang - ejabberd: Interessant projekt. Specielt fordi der allerede nu eksisterer en prototypeimplementation af Wave ovenpå ejabberd. Det tog dem efter sigende et par dage at skrive. Og det er ikke urimeligt; Erlang er ekstremt godt til protokolbehandling.

Erlang generelt: Fejler. Der er for lidt struktur over det sprog og for meget knopskydning i udviklingen. Derudover er det dynamisk typet og jeg har derfor meget svært ved at tro det nogensinde får en acceptabel performance til at kunne løse talknusningsproblemer. Til gengæld har det en rimeligt god multiprocesmodel i actor-modellen og det har vist sit værd af flere omgange som implementationssprog for meget store systemer.

Relationelle databaser vs Column stores: Pas på med at smide SQL på porten for tidligt. Mange column stores har decideret elendige queryinterfaces så du skal skrive bunker af manuel kode for at behandle dine data. Det afhænger naturligvis en del af datas beskaffenhed. Desuden er mange større systemer hos virksomheder godt tjent med relationelle databaser - de kører eksempeltvist med rigtig god skalering når samtlige cores og disk-storage ligger på den samme maskine. Og det kan det forventes at gøre i fremtiden. Og derudover passer data ofte rimeligt pænt i den relationelle model. Dertil kommer at SQL er et absolut vidunderligt sprog når man skal behandle store mængder data. Desværre er der mange programmører som ikke helt forstår modellen og det er synd.

STM - software transactional memory: Jeg tror ikke på det. Det kræver grundliggende shared state. Og shared state overlever ikke, tror jeg. Hver CPU får sin klump hukommelse og skal så kopiere data til de andre CPUers hukommelse. Jeg har meget mere fidus til en message-passing konstruktion fordi den passer bedre ind i en arkitektur uden shared state og cache-coherency. Den har også den fordel at have god teoretisk understøttelse i form af CSP og Pi-kalkyle. Det skal man ikke undervurdere væsentligheden i.

27
8. oktober 2009 kl. 21:35

Super godt indlæg.

Dog synes jeg absolut heller ikke vi skal af med RDBMS og SQL, dog skal vi være vågne for alternativerne, da de nogle gange passer langt bedre til problemstillingen (EAV modeller og grafer passer jo ikke ligefrem som hånd i handske i den relationelle model). Ligeledes er der andre sprog i ETL verdenen (SAS Datastep kan nævnes, ligeså kan Informatica), der er langt bedre end SQL til behandling af store datamængder, så længe data ikke skal behandles transaktionelt.

Disk store er allerede flyttet væk fra maskinerne, så det er ikke noget de heller kommer til i fremtiden. Det hedder i dag SAN og/eller iSCSI.

Jeg tror STM bliver til noget, men jeg ved ikke hvor udbredt det bliver. HTM er allerede en realitet (Azul Systems har sådan en appliance som er 800+ processer stor). Det ville da også være temmelig underligt at den teknologi som vi alle godt kan lide ved RDBMS, ikke skulle være god at genbruge.

26
8. oktober 2009 kl. 21:18

@Jesper

Nu har jeg kodet professionelt i Ruby (on/off) i små 3 år, så Erlangs dynamiske natur gør mig bestemt ikke noget :-)

Hvad angår talknusning så er det slet ikke Erlangs bord - SML/OCaml og lignende vil være meget bedre bud.

SQL - get over it! ;-)

29
9. oktober 2009 kl. 02:19

Hvad angår talknusning så er det slet ikke Erlangs bord - SML/OCaml og lignende vil være meget bedre bud.

Til parallelisering af teknisk/videnskablige anvendelser legede jeg i gamle dage (starten/midt 90'erne) med at bruge SISAL[1] og Occam[2], og selvom det er mange år siden nu, forekommer det mig at mange af de ideer, der fremkommer nu, også var aktuelle dengang.

Pt. håber jeg på (selvom det ser lidt sort ud) at Fortress[3] får vind i sejlene..

[1] http://en.wikipedia.org/wiki/SISAL[2] http://en.wikipedia.org/wiki/Occam_programming_language[3] http://en.wikipedia.org/wiki/Fortress_(programming_language)

28
8. oktober 2009 kl. 21:53

Jeg synes heller ikke at de dynamisk typede sprog gør ondt, om det så er Ruby, Python eller Groovy.

I hvert fald har jeg ingen produktivitetsforhindringer ved at bruge dem.

Jeg ved godt at mange vil påstå at statisk typede sprog er bedre og mere produktive da compileren tidligt fanger fejlene, og det kan da også være at nogen har fremlagt teoretiske videnskabelige bevise for det, men i praksis mangler beviserne stadig. Indtil nu er det modsatte vist tilfældet.

25
8. oktober 2009 kl. 21:16

@Jesper: Jeg kan ikke se, at column stores har været nævnt i debatten før. Mon ikke du mener "key-value" stores? (Man kan sagtens have SQL oven på column stores - jvf. Sybase IQ.)

7
8. oktober 2009 kl. 01:09

Jeg synes da det er en fallit erklæring for vores fag hvis nye cpu arktiekturer kræver nye sprog.

Nye? Haskell blev skabt i 1990.

Er "Flerkerne-problemet" ikke noget der bør løses på vm niveau??

Jo, på den VM som på magisk vis dukker op på din computer, skrevet i ... Java? C#? Men det bekymrer vi os ikke om her i landet, vi har travlt med at lave den næste SharePoint-installation!

10
8. oktober 2009 kl. 08:40

@ KRISTIAN THY

"nye" skal så tolkes som at man skal have et nyt sprog i sin vækrtøjskasse...

Der er helt sikekrt nogle kloge mennesker der sætter sig ned og løser problemet i en eller anden form for vm eller fortolker....løsningen af dette skal jo ikke lægge hos sharepoint/applikations udvikerne....det ville være en meget forkert prioritering...

8
8. oktober 2009 kl. 01:37

Hr. Baldur.

Tak fordi du præcisserer mit indlæg og giver mig ret.

I øvrigt giver jeg dig ret parallelitet og samtidighed er ikke noget snavns. Det er kun noget snavns når det bringes ind midt i løsningendomænet for en anden problemstilling, når den kan løses på et lavere abstraktionsniveau. Jeg ved ikke hvor meget samtidighed du putter ind i din SQL, eller lader du din RDBMS om at klare ærterne for dig?

Men du kan jo føre bevis for din påstand om at en VM ikke kan klare en stor mængde af samtidigheden (locking osv.)?

Min påstand er at maskinen fint klarer samtidighed, den skal bare instrueres rigtigt.

Nye? Haskell blev skabt i 1990.

Øhh så at nye arkitekturer kræver gamle sprog? Hvor vil du lige hen Kristian, bare diskutere?

Jo, på den VM som på magisk vis dukker op på din computer, skrevet i ... Java? C#? Men det bekymrer vi os ikke om her i landet, vi har travlt med at lave den næste SharePoint-installation!

Hvad betyder denne sætning - udover vrøvl?

9
8. oktober 2009 kl. 02:01

Jeg har set rigtig meget SQL som er skrevet forkert på grund af den tankegang.

Eksempel:

select balance from account where accountno = 123; {gem balance i variabel X} update account set balance = balance+X where accountno = 321; update account set balance = 0 where account = 123;

Ovenstående er ment som et eksempel på at flytte alle midler fra konto 123 til konto 321. Og det er åbenlyst forkert fordi nogen har glemt at skrive "select for update", "begin" og "commit" noget sted.

Det er min erfaring at rigtige mange programmører aldrig har hørt om disse begreber.

Der er endnu færre der forstår hvorfor ovenstående eksempel kan deadlocke selvom man har pakket det pænt ind i en transaktion.

11
8. oktober 2009 kl. 08:43

Nu holder jeg mig til F# som reference for det her indlæg fordi det er hvad jeg kender til. Simon Peyton-Jones vil jo helst lave alt i funktionelle sprog. Microsofts tilgang til F# er "hver ting til sin tid". Det er ikke meningen at F# skal erstatte alt andet, det er skal kun bruges når det giver mening. Det er den samme idé man ser med f.eks. dynamic i C#4.0. Det er ikke meningen at alt skal være dynamisk bare fordi man reelt set kan.

Jeg kan anbefale at man ser "An Introduction to Microsoft F#" fra PDC2008 http://channel9.msdn.com/pdc2008/TL11/Det handler selvfølgelig primært om F# men der af også emnet om hvorfor er der overhovedet brug for F#. der kan man se eksempler både på hvor det er smart at bruge F# og hvor det ikke er.

Vi skal kunne begge dele, ikke bare det ene eller det andet ;)

4
7. oktober 2009 kl. 21:11

Isk, Haskell findes i mange Linux-distributioner - lige til at installere via respektive pakkesystem.

5
7. oktober 2009 kl. 22:49

@Mikkel Jo det er det lige præcist, og det er også det man forsker i. Azul Systems har lavet en dedikeret Java VM implementeret i hardware, hvor du ikke behøver forholde dig til at maskinen har 8 milliarder processorer, det klares af VM.

Lad os nu enes om at få alt det der snavns der kan klares af maskinerne (det er jo altså derfor vi har opfundet dem) lavet af maskinerne. Der er ingen grund til at vi skal bebyrdes med det.

Skal en hardwaremæssig bagatel som ikke har noget med den problemstilling en programmør skal løse at gøre, bestemme hvilket programmeringsparadigme han skal bruge? Næppe. At man skal skifte programmeringsparadigme så mange lag oppe hvor moderne fortolkede programmeringssprog befinder sig for at man ikke bliver forstyrret af evolutionen på hardwarefronten er da galimatias, hvor er den løse kobling til platformen? Jeg sidder da heller ikke hele tiden og tager stilling til trådmodellen på Windows XP kontra Solaris eller Linux når jeg udvikler Java kode. Den mapning foretager JVM. Jeg kan så optimere min trådmodel i OS (dog kun Solaris og frem til Solaris 8) hvis jeg har lyst bagefter, men jeg ændre da ikke en linie kode.

6
8. oktober 2009 kl. 00:10

Hvis man tror at samtidighed er noget snavs som maskinen bare klarer, så har man ikke sat sig ind i emnet.

Hvis du skriver dit program så det forudsætter at A udføres før B, så er det ikke bare sådan for en oversætter at omformulere dit program, så at A og B kan udføres samtidig.

Det har sådan set ikke noget med sprogparadigme eller mutable vs immutable at gøre. Det er bare nemmere at formulere problemet på en paralleliserbar måde, når man holder sig til immutable datastrukturer - uanset sprog.