Demands of parallel processing January 09, 2008 22:11 over 4 years ago
På flere konferencer i løbet af 2007 var der flere bud på hvordan vi attakere parallel processering på multiple cores. Skal vi nu alle til at lære nye programmeringssprog for at kunne udnytte nye cores eller er det ikke nemmere at tilpasse allerede velkendte sprog til at kunne håndtere mere end en CPU?
Ideen er at skabe mulighed for at køre processer parallel men transparent for programmøren. Lagacy systemer bør kunne overføres til multicore applikationer med mindst mulig modifikation og uden at tilføre kompleksitet med ting som thread synchronization.
Men jeg kan ikke lade være at tænke på om den stigende trend imod parallelitet på hardwaresiden vil skabe et skifte mod multithreaded, managed programming platforms som Java.
Oprindeligt har jeg været af den opfattelse at vi går mod flere nye mere domain specifikke sprog som fx Erlang, Haskel og andre funktions orienteret sprog. Dette kan muligvis være en løsning men kun for de få ægte specialister. Løsningen for masserne er en anden. For mig gælder det at når man adoptere et nyt sprog adoptere man også den tankegang som sproget er udviklet med. Desværre er det kun syntaks der betyder noget for de fleste og ikke lingvistik, som jeg ser det er ikke hensigtsmæssigt at benytte et funktions orienteret sprog på en objekt orienteret tanke måde.
At maskinerne får flere/mange CPU rejser en interessant problematik for enhver programmeringsplatform. Efterhånden som man addere flere cores vil strømforbruget stige og dermed vil der genereres mere varme. En måde at reducere strømforbruget er at nedsætte hastigheden på de enkelte cores.
Resultatet er at hver single thread of execution ville køre hurtigere på en single-core CPU end på en multi-core CPU.
Det åbenlyse svar er nu at dele processerne op på fler individuelle processer. Java er jo multithreaded by nature, så Java er den naturlige løsning til at eksekvere processer på muliti-core CPU’er? Øh, nej. Bemærk at jeg har sprøgsmåltegn efter den sætning.
Java er ikke konstrueret til at udforske flere processer eller flere cores. Helt frem til Java version 1.4 var Java berømte garbage collection i vejen for parallel eksekvering, den er single-threaded og stallede alle programmer når den køre ligegyldigt hvor mange CPU’er der findes.
Java version 1.6 har en masse nye tuning parameters til at minimere gc på muliti-core processore men er lang fra perfekt. Måske netop derfor arbejder IBM på X10, et Java relateret sprog som er designet specielt til at udnytte parallelle processorer. Se:
“The Experimental Concurrent Programming Language (X10) ":http://x10.sourceforge.net/x10home.shtml
Interessant er det også at Intel praler med quad-core performance på Java platform mens de benytte en ikke Sun JVM til målingerne. Det ser ud til at JRocket køre langt hurtigst når Intel tester deres topprodukter.
Jeg tror ikke et enkelt værktøj eller sprog vil kunne være det åbenlyse valg for multiple cores eller transparente CPU’er. Men Java har potentiale til at udnytte multiple cores uden er større ekstra arbejde for programmøren og måske derfor får sin anden ungdom. Dog, selvom Java synes at have en fordel her er der mange andre managed, multithreaded sprog som har chancen, fx Python og Ruby.
By Frank Vilhelmsen - 2 tags: architecture concurrency - Add comment