[Java] Programmeren voor multicore

[Deddiekoel]

Ik heb onlangs een nieuwe PC gekocht en hoewel ik het niet direct nodig vond heb ik toch een dualcore systeem gekocht (Socket AM2 Athlon 64 X2 3800+).

Reden om toch voor dualcore te gaan was om te kijken wat er nodig is om gebruik te maken van meerdere cores in java-programmatuur. Nu ben ik geen java-wizard, maar toch vroeg ik me af wat je allemaal moet/kunt doen in java om gebruik te maken van meerdere cores? Kun je uberhaubt wel iets doen of worden mutithreaded applicaties door de JVM direct over meerdere cores verdeeld?

[Vaudtje]

Het is in principe gewoon een kwestie van met threads programmeren, dan is het vervolgens aan de JVM en het OS op te kiezen op welke core(s) er gedraaid gaat worden.
Aangezien die twee er meestal beter in zijn om te kiezen welke resources gebruikt moeten worden dan de programmeur, lijkt het me niet zinnig om daar zelf veel moeite in te steken (als het al kan, in verband met de abstractie in de VM), behalve zorgen dat je dus meerdere threads hebt die gezamenlijk de workload delen. Eventueel kun je nog wat priorities zetten, maar dat is het volgens mij wel zo'n beetje.

[BalusC]

De JVM is op zich al multithreaded. Ook de OS kan prima zelf threads verdelen over de CPU's. Je hoeft in principe eigenlijk niks te doen Tenzij je bepaalde zware eisen hebt, maar daar hebben we op het moment geen inzicht in, aangezien je niet meldt wat je precies wil bereiken.

[Deddiekoel]

Ik heb nog geen direct doel voor ogen. Dacht eigenlijk wel dat de JVM het zou afhandelen. Reden dat ik het toch wilde controleren was dat je altijd leest dat dualcore alleen lekker werkt als de software er rekening mee houdt.

[misfire]

Java en het OS regelen dit inderdaad voor je, zolang je maar meerdere threads gebruikt. Wat wel extra belangrijk is bij een multi-core platform is dat je netjes multi-threaded code programmeert. Je moet gebruik maken van de synchronisatie mechanismen in Java als je informatie tussen threads uitwisselt, anders loop je de kans tegen allerlei obscure bugs aan te lopen. Brian Goetz heeft een goed verhaal gegeven op de afgelopen Javapolis, wellicht interessant om de gratis beschikbare on line presentatie te bekijken. Hij is er ook geïnterviewd over multi-core problemen, ook heel interessant om eens te kijken als je multi-core doet op Java.

[Verwijderd]

misfire schreef op zondag 06 augustus 2006 @ 15:38:
Java en het OS regelen dit inderdaad voor je, zolang je maar meerdere threads gebruikt.

Zo makkelijk is het niet altijd. Als je een enkele berekening wilt opsplitsen in sub-berekeningen dan heeft dit eigenlijk alleen zin performance wise als je aantal worker threads overeenkomt met het aantal cpu's dat er aanwezig is. Je kunt bijvoorbeeld wel een berekening door 16 threads laten uitvoeren, maar als je precies 2 cores hebt is 2 worker threads effecienter (context switches en het opslitsen / joinen van resultaten is niet gratis).

Voorderest moet je er ook voor zorgen dat je threads een redelijke hoeveelheid werk te doen hebben. Gewoon "meerdere threads gebruiken" is zinloos als je bijvoorbeeld (om maar wat heel sufs te noemen) een enkele hashmap lookup door een aparte thread laat doen. De overhead om de opdracht naar de thread te sturen, de wacht tijd tot die thread start, en de overhead om het resultaat terug te krijgen is dan groter dan het zelf doen.

Sommige rekenkundige problemen zijn op natuurlijke wijze recursief op te splitsen, andere zijn dat niet. Soms heb je de situatie waarbij er niet 1 berekening plaatsvind, maar waar er logischer wijs min of meer autonome 'entities' in je applicatie aanwezig zijn (simpelste voorbeeld: de GUI thread en de worker thread).

Net zoals je bij OO design moet nadenken over hoe je de totale functionaliteit van je applicatie zo meest optimaal mogelijk over een set classes verdeeld, zo moet je in het laatste geval ook nog nadenken over hoe je deze indeling in classes weer projecteerd op threads. Dit is zeker geen triviale bezigheid.

In dit laatste geval speelt overigens niet dat je aantal aanwezige cpu's moet overeenkomen met het aantal threads. Dat geldt alleen voor puur rekenwerk, en niet voor de logische opdeling van een app in threads, waar veel threads typisch voor langere tijd slapen.