'Onvoldoende parallelle software voor computerclusters'

IBM's 'chief architect for next-generation systems software' heeft benadrukt dat softwareleveranciers zich moeten gaan aanpassen aan de toenemende populariteit van multicoresystemen.

Uit de Top500-lijst van supercomputers blijkt dat steeds meer berekeningen uitgevoerd worden door clusters van gewone Linux-systemen. Daarnaast winnen multicoresystemen als de Cell-processor steeds meer aan populariteit, maar volgens IBM maken softwarebouwers lang niet voldoende gebruik van de mogelijkheden van die systemen. Het bedrijf is momenteel druk bezig met het bouwen van de RoadRunner-supercomputer, die gebaseerd zal zijn op een cluster van Opteron-systemen en die 1,6 petaflops moet kunnen gaan neerzetten. Om de volle rekenkracht van dit systeem te kunnen benutten, zal er echter heel wat aandacht besteed moeten worden aan de programma's die op de cluster moeten gaan draaien. Hoewel Moore's Law in feite louter over het aantal transistors op een chip gaat, meent IBM dit toenemende aantal te kunnen vertalen naar een grotere rekenkracht. Op dat gebied zal Moore's Law volgens IBM nog wel een tijdlang geldig blijven, maar wat het nuttig gebruikmaken van die kracht betreft, hikt software volgens het bedrijf tegen de grenzen van de wetmatigheid aan.

Reacties (32)

[0rbit]

Tja, niet verrassend. In mijn ervaring is het niet moeilijk om je code bijvoorbeeld multicore geschikt te maken, maar daarna begint de ellende eigenlijk pas.

De hele software architectuur moet meestal op de schop om daadwerkelijk een merkbaar snellere berekening op te leveren. Als dit allemaal gelukt is dan krijg je vaak nog bij het uitgeven van de resultaten in bijvoorbeeld een console-venster problemen als je meerdere threads van de gelijke methode gebruikt. Dan moet je al gauw asymetrisch aan het werk (niet ideaal) of je moet variabelen gaan locken. Enfin, dat is nog wel op te lossen.

Dan zijn er nog de applicaties die je met geen paard in een multithread omgeving omgeschreven krijgt. Gelukkig zijn die applicaties schaars.

Uiteindelijk ontkom je natuurlijk niet aan Amdahl's Law...
http://en.wikipedia.org/wiki/Amdahl's_Law

[jqv]

Een van de redenen voor deze apparaten is natuurlijk het berekenen van deze wetmatigheid...

[justice strike]

pff laten we ook niet vergeten dat sommige talen gewoon echt slecht zijn gebouwd voor multicore laat staan multiprocessor.

Neem bijvoorbeeld java, kan zowel threads als rmi aan. Maar laten threads nou net objecten zijn. En wat is nou juist zo kostbaar object creation and destruction. Je moet je heel goed gaan buigen over hoe je threads wil gaan gebruiken de kans is namelijk groot dat als je je daar niet over buigt dat de speedup in het negatieve getrokken zal worden.

IMHO is dat een slechte zaak. Talen moeten transparant zijn en moeten je in staat stellen om je te focussen op het oplossen van het probleem ipv alle side conditions.

MPI is bijvoorbeeld weer wel een goede taal/libary. Werkt snel, werkt goed, werkt zoals je het verwacht. Je kunt gewoon je focussen op het probleem oplossen en je hoeft je geen zorgen te maken over object creation en/of destruction oid. Hooguit communicatie lag.

[Floort]

Ik heb een heel klein beetje ervaring met Labview, en dat lijkt me juist heel geschikt voor multicore computers. De mannier van programmeren zorgt er automatisch voor dat het hele programma opgesplitst word in onafhankelijke deeltaken.
Ik denk niet dat Labview geschikt is voor zwaar rekenwerk, maar een soortgelijke programmeeromgeving zou super zijn voor parallelle processen.

[jj71]

Neem bijvoorbeeld java, kan zowel threads als rmi aan. Maar laten threads nou net objecten zijn. En wat is nou juist zo kostbaar object creation and destruction. ...

Sorry hoor, maar er klopt geen bal van wat je zegt over Java. Het lijkt alsof je de klok hebt horen luiden, maar je weet niet waar de klepel hangt.

Een thread is een object, maar stel dat je 4 cores hebt en je maakt 4 threads aan, dan zijn dat maar 4 objecten. Het aanmaken van die 4 objectjes gaat de performence niet beïnvloeden.

[justice strike]

je maakt meer dan 4 objecten aan. Je vergeet dat threads zelf ook objecten nodig hebben. Verder vergeet je ook dat threads een bepaalde functie hebben, mocht die fuctie afgelopen zijn hebje andere threads nodig. Kortom je moet veel meer gaan nadenken over je thread creation en destruction.

Vergelijk het maar met mpi. Ik kan met mpi binnen 2 dagen een sequentieel probleem (ida bijvoorbeeld) oplossen. Java is daar veel lastiger in.

[Anoniem: 3652]

Neem bijvoorbeeld java, kan zowel threads als rmi aan. Maar laten threads nou net objecten zijn. En wat is nou juist zo kostbaar object creation and destruction.

uhuh..

The common code path for new Object() in HotSpot 1.4.2 and later is approximately 10 machine instructions (data provided by Sun; see Resources), whereas the best performing malloc implementations in C require on average between 60 and 100 instructions per call (Detlefs, et. al.; see Resources).

bron

[justice strike]

leuk voorbeeld. Maar dat is new Object(); Dat is een totaal leeg template voor je eigen object. In de praktijk gebruik je NOOIT een leeg object.

Met andere woorden dat is een leeg object. Met andere woorden dat is geen eens een thread,immers een thread is geen leeg object maar een thread object. Laat staan een zelf gemaakt object met je eigen code.

het is ook niet mogelijk. Stel je wil een object maken met geheugen ruimte voor een gb en de constructor wijst waardes toe aan die die gb opvult. Dan wil jij mij zeggen dat de object creation maar 10 machine instructions lang duurt. Totaal onmogelijk.

Het is leuk dat hier 4 reacties over komen. Maar totdat je echt geprogrammeerd hebt met threads in java. Is het hoogstens theoretisch geneuzel over dat het wel snel "zou moeten zijn" Laat de praktijk nou net anders zijn.

[Anoniem: 207146]

Ik heb wel degelijk aardig wat ervaring met threads in java en heb nog nooit performace problemen gehad met de thread implementatie in java. De thread implementatie in java volstaat ruimschoots voor de problemen waar java zich op richt. Trouwens het meerendeel van de java applicaties die zowat overal gebruikt worden (en dat zijn er veel) zijn al multi threaded, iets wat je niet zou verwachten van een taal die 'slecht gebouwd' is om met threads om te gaan.
Natuurlijk zijn andere talen / tools beter geschikt voor meer specifieke domeinen, als ik wetenschappelijke software moet schrijven zal ik ook wel eens naar Matlab, Fortran, MPI en dergelijke kijken.
Om er nu ineens objecten bij te sleuren als reden waarom java threads traag zouden zijn gaat me wel een beetje te ver. Dat is een heel andere discussie, OO versus non OO, een discussie die zo'n 20 jaar geleden al afgehandeld is.

[justice strike]

Ik heb wel degelijk aardig wat ervaring met threads in java en heb nog nooit performace problemen gehad met de thread implementatie in java.

Die twee statements gaan niet samen. Of je hebt veel ervaring en je bent wel peformance problemen tegen gekomen. Of je hebt weinig ervaring en hebt geen peformance problemen ervaren.

Programmeer maar een ida algoritme. En probeer die maar eens vrijwel linear te laten zijn met een sequentieel oplossing. Dan zul je merken dat dat lang niet zo makkelijk voor elkaar te krijgen is.

Trouwens het meerendeel van de java applicaties die zowat overal gebruikt worden (en dat zijn er veel) zijn al multi threaded, iets wat je niet zou verwachten van een taal die 'slecht gebouwd' is om met threads om te gaan.

programma's kunnen multithreaded geschreven zijn. Maar dat zegt niets over de efficientie van de programma's. Naar mijn ervaring is het zeer moeilijk om voordeel te halen tov een sequentiele oplossing.

Natuurlijk zijn andere talen / tools beter geschikt voor meer specifieke domeinen, als ik wetenschappelijke software moet schrijven zal ik ook wel eens naar Matlab, Fortran, MPI en dergelijke kijken.
Om er nu ineens objecten bij te sleuren als reden waarom java threads traag zouden zijn gaat me wel een beetje te ver. Dat is een heel andere discussie, OO versus non OO, een discussie die zo'n 20 jaar geleden al afgehandeld is.

Dit is geen OO discussie. Ze hadden een hele andere implementatie kunnen kiezen mbt parallel computing. helaas hebben ze dat niet erg goed gedaan. Maar dit is mijn mening, met mijn ervaringen met die taal. Je mag er over discuscieren met mij als je dat zint.

[Anoniem: 207146]

Zoals ik eerder al duidelijk gemaakt had. Java is een taal die gericht is op het maken van bedrijfssoftware.
Of je nu er nu makkelijk een AI problemen mee kan oplossen of niet daar liggen bitter weinig mensen van wakker. Als jij je vooral bezighoud met software waar zware algoritmes geparallelliseerd moeten worden dan zal je wel beter af zijn met mpi. Maar een heel groot deel van de software is niet gelimiteerd door de snelheid waarop men een algoritme doorloopt maar door het wachten op allerlei IO resources. Iets dat zich heel makkelijk laat parallelliseren door een thread implementatie zoals die bestaat in java.
Vandaar dat het wel heel erg kort door de bocht is om te beweren dat java threads 'slecht' zijn. Het beste bewijs hiervan is misschien wel dat er quasi geen gebruik word gemaakt van java mpi libraries, dat terwijl de java wereld er normaal nogal snel bij is om de mindere punten van java weg te werken door middel van externe libraries/frameworks (Spring vs J2EE, log4j vs java.log, ...)

[Anoniem: 3652]

Ik ken de performance van Java threads niet in vergelijking met de performance van niet Java threads. Het zou best kunnen dat de implementatie van Java niet optimaal is, zoals jij beweert. Maar heb je cijfers?

Waar het mij om ging was de bewering dat Java traag zou zijn. Dit was 10 jaar geleden misschien zo, in de tijd van java 1.1. Tegenwoordig kan de performance van Java zich meten met een willekeurige taal. Ok, het zal niet zo snel zijn als een applicatie die speciaal voor een bepaalde machine is geschreven in assembly, maar dat is geen realistisch scenario. Zeker niet in deze context.

[justice strike]

Waar het mij om ging was de bewering dat Java traag zou zijn. Dit was 10 jaar geleden misschien zo, in de tijd van java 1.1. Tegenwoordig kan de performance van Java zich meten met een willekeurige taal.

nee ik bedoel Java is traag als je een Java sequentieel prgoramma vergelijkt met hetzelfde programma maar dan threaded. heeft niets met andere talen te maken.

[justice strike]

Als jij je vooral bezighoud met software waar zware algoritmes geparallelliseerd moeten worden dan zal je wel beter af zijn met mpi. Maar een heel groot deel van de software is niet gelimiteerd door de snelheid waarop men een algoritme doorloopt maar door het wachten op allerlei IO resources. Iets dat zich heel makkelijk laat parallelliseren door een thread implementatie zoals die bestaat in java.

Ten eerste I/O laat zich niet makkelijk paralleliseren. de thread blocked gewoon en de rest gaat door. Dat is geen paralleliseren. Paralleliseren betekent dat je meerdere processoren benut. Dat doe je niet als je op IO resources wacht, de thread doet namelijk gewoon niets dan.

Verder hoe heet dit artikel

'Onvoldoende parallelle software voor computerclusters'

Jij vergeet voor het gemak even de context omdat het jou argumentatie niet ten goede komt. Zo kan ik ook elke discussie winnen.

[Anoniem: 207146]

Zoals eerder al aangehaald is het aanmaken van objecten in een moderne JVM een lichte operatie. Als er echt heel veel kortlopende threads moeten worden aangemaakt kan je nog altijd met een threadpool werken.
De ondersteuning voor threads in Java 5 is volgens mijn mening alles behalve slecht, en volstaat voor grootste gedeelte van de problemen die in het toepassingsveld van Java liggen. Daarbij komt dan nog eens dat langs de serverkant al veel applicaties transparant schalen naar meerdere cpu's doormiddel van applicatie containers en andere frameworks.

[bbob]

Zie daar dus het probleem van multicore. Het is leuk om te hebben maar het is toch echt de software die het maximale er uit moet halen.
Juist die software is zoals ze er nu pas achterkomen onvoldoende om het maximale uit je cpu te halen.

Je kan je dus zeker afvragen wat op dit moment de grote meerwaarde van al die quad cores is als de software ze niet maximaal gebruikt.

Er wordt nu veel waarde gehecht aan performance per watt maar met slechte software ziet die performance per watt er ineens stukken slechter uit.

[Sentry23]

Voor mensen die het echt intressant vinden om te zien hoe en wat je kan en moet doen voor goeie parallel code, staat er een leuke set MIT lectures over Cell en parallel programming op deze site: http://cag.csail.mit.edu/ps3/lectures.shtml

(de Roadrunner is een cluster van Opteron en Cell procs (Opteron voor scalar en Cell voor vector code))
Met enkel Opterons was die performance redelijk onmogelijk geweest.

[RedRush]

hmm.. goed idee, betere software voor meerdere cores

1,6 petaflops is enorm veel toch, voor zware berekeningen en voorspellingen is misschien wel nodig, maar die software word daar speciaal op gebouwd, om zulk soort computers te ondersteunen lijkt mij.

[Astennu]

Helemaal als de Quad cores zo meteen komen. Nu wordt op core 1 het zware programma gedraaid en die doet het rekenwerk. En Core 2 is bezig met windows en de VGA driver enz. Maar met een Quad core staan 2 andere cores echt helemaal niets te doen.

Misschien kunnen ze dan ook nog meer rekenkracht uit die X1950 en straks R600 kaartjes halen. De X1950 XTX kon nu al iets van 360 Gigafops halen als ik me niet vergis. En de R600 zou er meer dan 500 kunnen.

[jqv]

het gaat hier niet om thuis pc-tjes...het gaat om grote apparaten zoals de BlueGene of te wel supercomputers.

[jqv]

Die is niet te koop in de winkels nee...

en inderdaad voor zware berekeningen voor onder andere het weer, kernfusie en kernexplosies zijn deze machines uitermate geschikt...

en het gaat niet om meerdere cores, maar om enorm veel cores...

[Dark Angel 58]

64 bit software?

[Astennu]

Idd hier mag ook wel eens aandacht aan gegeven worden. Stom van MS om vista ook in 32 Bit only uit te geven. Ze hadden gewoon 64 only moeten uitgeven. 64 Bit versie gebruikt Windows on Windows om een 32 Emulatie te doe. is meestal even snel misschien 3% trager. Drivers moeten wel 64 bit zijn. Maar we moeten gewoon naar 64 bit software toe dat is de toekomst.

[Envy007]

Is dat voor een consumenten besturingssysteem een vereiste dan?
Ik zie nu wel de eerste systemen met 4GB opduiken maar degene die dat in zijn systeem drukt, weet ook wel dat het besturingssysteem mee overweg moet kunnen. Verder kan ik niet heel veel redenen bedenken dat een thuisgebruiker of een gemiddelde gebruiker in een bedrijf een 64 bit besturingssysteem moet gebruiken.

Ze hadden het wel kunnen doen, maar dan moet je de mensen eens horen die vast zitten aan een 64 bit besturingssysteem wat meer geheugen gebruikt in vergelijking met een 32 bit besturingssysteem.

64 bit is nog steeds niet volwassen, zeker in de consumentenmarkt niet. Het bestaat al sinds 2003, Microsoft heeft netjes gewacht tot Intel het ook had voor de introductie van 2003 en XP 64 bit in 2005 en nu in 2007 hoor je er nog weinig van.

[Anoniem: 57258]

Apart dat dit bericht naar buiten komt, terwijl 1 van de grote grondleggers en bedenkers hiervan net ergens verloren? is op de grote oceaan.

hier nog een interview met Grant-Guru; Jim Gray
http://www.regdeveloper.co.uk/2006/05/30/jim_gray/

o.a. over dat programmeurs niet paralel programeren..

info over Jim/James? Gray ->
http://en.wikipedia.org/wiki/James_N._Gray

edit -> met de geweldige vergelijking dat single coding moet gezien worden als borduren. En paralel coding als een kookboek (met meerdere dingen tegelijk bezig)

[EIo]

Bedoel je niet Jim Gay?? Programmeren een beetje vergelijken met borduren en koken... pffff...

[Anoniem: 187167]

Waarom kunnen ze compilers gewoon niet zo maken dat die code meteen al goed parallel kan werken? Nu moeten programmeurs beter parallel programmeren terwijl als je dat aan de compiler overlaat dan hoeven alle programmeurs dat niet te leren want het wordt al goed gecompiled.
Tevens is het zo dat als je dat plaats in de compiler dan hoeven programmeurs van de compiler alleen maar te richten op het het goed compilen van code zodat het goed parallel loopt ipv al die programmeurs.

Kan iemand misschien hier wat over uitleggen/vertellen?

[Anoniem: 207146]

Er zijn nu al compilers die automatisch parallelle stukken uit code kunnen halen. (Een moderne cpu (zelfs single core) doet op een ander niveau overigens min of meer hetzelfde). Maar dit beperkt zich tot stukken code waarvan de compiler zeker kan zijn dat ze onafhankelijk van elkaar kunnen uitgevoerd worden. Het merendeel van de code laat zich echter niet zo makkelijk ontrafelen door een compiler, vandaar dat de programmeur instructies moet toevoegen die expliciet uitleggen hoe stukken code onafhankelijk van elkaar uitgevoerd kunnen worden om uiteindelijk toch noch het gewenste resultaat te leveren (hier komen dingen zoals OMP en de thread ondersteuning van Java en .NET in het spel).
Voor specifieke domeinen zal men wel met oplossingen komen die dit kunnen automatiseren (server applicaties onder J2EE, een FPS gemaakt met de Unreal 3 engine), voor andere meer generieke software zie ik niet zo onmiddelijk een drastische simplificatie opduiken om multi threaded te programmeren.

[Sentry23]

In de link die ik hier boven heb gepost staat er vrij veel, maar het is wat pittig om doorheen te worstelen als je alleen wil weten waarom wel of niet..

In deze PDF http://cag.csail.mit.edu/...-lecture4-concurrency.pdf staat (voor mijn gevoel) erg goed aangegeven wat het probleem kan zijn met deadlocks en race-conditions met eenvoudige voorbeeldcodes.

Het komt er op neer dat je moet weten wat de code doet/moet doen om parallel tasks netjes af te kunnen handelen. Dat kan je oplossen door je code netjes te schrijven in 'standaard' talen, of door over te schakelen op een nieuwe generatie talen die expliciet voor parallel programmeren bedoeld zijn. en dat laatste is nogal een stap voor veel coders.

Vandaar dat de oplossing niet zit in het schrijven van een C compiler die alles netjes zelf oplost. Dat is eigenlijk niet te doen.

[smokalot]

ik snap niet zo goed of het nou over desktops of servermachines gaat, maar in beide gevallen is het niet zo'n probleem imho.

Servers doen vaak veel dingen tegelijk, en gaan dus prima om met hun meerdere cores.

Desktops hebben 99% van de tijd toch niks te doen. Spellen vragen vaak het uiterste, en misschien een paar professionele audio/video/graphics pakketten, maar er zijn maar weinig dingen waarbij het een probleem is dat de CPU te traag zou zijn.

Multicore proc terwijl er maar 1 core 100% belast wordt houdt juist je systeem lekker responsief.

[jqv]

het gaat om een cluster van computers ook wel super computers genoemd

[ejabberd]

Ik zal het kort houden: "functionele programmeertaal" en Erlang. Twee kwaliteitslinks hierover zijn: http://www.defmacro.org/ramblings/fp.html (Functional Programming For The Rest of Us) en http://www.defmacro.org/ramblings/concurrency.html (Erlang Style Concurrency)