Flere CPU-kerner tvinger udviklere over i funktionelle sprog

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.

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.«

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.«

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (30)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Nikolaj Brinch Jørgensen

@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.

  • 0
  • 0
Baldur Norddahl

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.

  • 0
  • 0
Kristian Thy

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!

  • 0
  • 0
Nikolaj Brinch Jørgensen

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?

  • 0
  • 0
Baldur Norddahl

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.

  • 0
  • 0
Mikkel Bruun

@ 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...

  • 0
  • 0
Torsten Holtse

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 ;)

  • 0
  • 0
Torben Mogensen Blogger

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??

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.

  • 0
  • 0
Nicolai Møller-Andersen

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.

  • 0
  • 0
Jesper Louis Andersen

Æ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.

  • 0
  • 0
Nikolaj Brinch Jørgensen

@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.

  • 0
  • 0
Kim Dalsgaard

@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.

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!

  • 0
  • 0
Nikolaj Brinch Jørgensen

@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???

  • 0
  • 0
Nikolaj Brinch Jørgensen

@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! :-)

...

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.

  • 0
  • 0
Kim Dalsgaard

Ø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 :-)

  • 0
  • 0
Nikolaj Brinch Jørgensen

@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?

  • 0
  • 0
Jesper Louis Andersen

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.

  • 0
  • 0
Nikolaj Brinch Jørgensen

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.

  • 0
  • 0
Nikolaj Brinch Jørgensen

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.

  • 0
  • 0
Jens Katz-Kolberg

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)

  • 0
  • 0
Jens Madsen

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.

Hvor godt skal det paralleliseres? Hvor godt skal det optimeres? Hverken parallelisering, eller optimering, kan gøres optimalt, uden brug af uendelige resourcer. Men skal det ske optimalt?

Vi kan gå ud fra to yderligheder. Enten, at skrive alt 100% parallelt, så hver enkelt plus operation udføres parallelt. Derved opstår millioner af parallele processer. En for hver operation, og mange for hver linie. Problemet er nu ikke at parallelisere - men det modsatte. At få de mange processer mapped ind på nogle få CPU'er, som sekventiel kode, eventuel VLIW kode.

Det problem, er faktisk mindst ligeså interessant, som at parallelisere!

Kan vi finde en algorithme, som effektivt tager et nærmest uendeligt antal processer, og mapper det effektivt ind på et endeligt antal CPU'er, der hver især udfører indstruktioner i rækkefølge, eventuelt VLIW baseret?

Hvis et program opfattes 100% parallelt, så vil ikke opstå de deadlocks som låser programmet. Kun, hvis der er afhængigheder, vil det som afhænger af problemet låses.

Ligesom en deadlock kun relatere til de data den vedrører, så gælder samme med pauser. En delay, uden der står hvad der skal forsinkes, vil ikke blive udført. Det skal decideret stå, at X skal forsinkes, eller Y skal forsinkes.

Nogle af de problemer, der er med parallelisering af sekventiel kode er f.eks. delays. I sekventiel kode, er ikke angivet hvad som skal forsinkes, og derfor må man forsinke alle processer i et paralleliseret program, når der er en delay. Har du eksempelvis to fuldstændigt uafhængige dele af et program, hvor første del initialiserer musen, og anden halvdel initialiserer lydkort - begge dele har pauser i sig, så vil de to dele ikke kunne paralleliseres på grund af pauserne. Det er nemt at se, at de to dele ikke berører hinanden funktionsmæssigt, men pauserne i sekventiel kode dikterer, at problemet ikke må blive færdig før summen af pauserne er udløbet. Årsagen er, at pauserne ikke relaterer til noget, og det er umuligt at sige, at pauserne for henholdsvis mus og lydkort er uafhængige. Pauser, skal i et parallelt sprog ikke eksistere, eller altid arbejde på data, f.eks. variable.

Et andet problem er anvendelsen af pointere. En pointer, svarer til et index, i en stor ram. Men virkeligheden er, at pointere er ustruktureret, og det er årsagen til, at problemet ikke lader sig løse nemt. Når det er svært at parallelisere sekventielle sprog som C og C++, så skyldes det strukturmæssige problemer i sproget. Paralleliseringsproblemer opstår netop samme sted, som software problemerne. Pointere er noget bras.

Brugen af dynamisk hukommelse, er ustruktureret i de fleste sprog, og det gør det ikke kan paralleliseres. Problemet svarer til GOTO i basic. Det er tale om strukturer, der ikke lader sig parallelisere, på samme måde som GOTO havde svært ved at lade sig analysere. Løsningen dengang var at gå bort fra GOTO. Løsningen på pointer problemet, er at gå bort fra pointere som vi har idag, og lave sproget så det kan paralleliseres.

Det er muligt at lave sekventiel kode, som automatisk kan paralleliseres, hvis du sikrer sproget er udviklet med henblik på det.

Det væsentlige er at få et sprog, hvor koden ikke skal skrives til antallet af CPU'er, eller ALU'er. Det kan ske ved at udvikle parallele sprog, hvor alt beskrives parallelt, eller sekventielle sprog, hvor at problemerne som findes ved parallelisering tages ud af sproget, og andre metoder bruges.

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