[Java/threads] Geen volledige CPU usage

[Verwijderd]

Voor school moeten we een CPU intensief algorithme multithreaded maken. Vervolgens runnen op een multi processor systeem en dan de speedup berekenen.

Nou heb ik zelf zo'n Duo core van intel dus dat kan ik op mijn eigen systeem testen.

Als ik de sequenciele versie draai komt mijn windows taakbeheer op +/- 54% dus één core word volledig benut en de andere core laat mijn windows draaien.

draai ik vervolgens de threaded versie dan krijgt mijn java.exe "slechts" 70-80% van mijn cpu de rest lijkt windows te reseveren.

Dat wil ik eigenlijk niet. eigenlijk moeten beide threads samen de cpu volledig benutten.
zodat ik kan zeggen 2x meer cpukracht resulteerd in 1,8x zo snel

Kan ik in windows(xp) aangeven dat het systeem gerust 100% gebruikt mag worden? iets als Nice in linux bestaat er naar mijn weten niet of wel?

(helemaal 100% aan java geven zal niet lukken dat snap ik)

[whoami]

draai ik vervolgens de threaded versie dan krijgt mijn java.exe "slechts" 70-80% van mijn cpu de rest lijkt windows te reseveren.

Dat wil ik eigenlijk niet. eigenlijk moeten beide threads samen de cpu volledig benutten.
zodat ik kan zeggen 2x meer cpukracht resulteerd in 1,8x zo snel

afaik en imho is dat onmogelijk.
Als jouw app 100% cpu krijgt, hoe kan windows dan nog reageren op andere commando's die je geeft ? (MouseMove, notepad openen, start menu openen, ik zeg maar wat).

[Kwistnix]

Je kan in Java de prioriteit van je threads hoger instellen, maar dat garandeerd niets.
Al geprobeerd om javaw via Windows taakbeheer een hogere prioriteit te geven?

[ Voor 3% gewijzigd door Kwistnix op 09-01-2007 23:16 ]

[Jaap-Jan]

Welk proces krijgt de rest van de CPU-tijd toegewezen? Oftewel, is er een ander proces wat ook veel CPU-tijd vraagt? Misschien dat je de gecompileerde klasses ook on-line kunt zetten? Ik heb een Core Duo T2500 waarop ik wel even kan testen.

[Verwijderd]

@whoami Hoe kan het dan dat als er een programma goed in de soep draait dat je muis trager gaat? het lijkt me dat de CPU usage dan zeer dicht bij 100% komt.

Jah met this.setPriority(10) in een thread class kun je aangeven wat je prioriteit is. maar wat ik daarvan op inet heb gevonden is dat dat vooral relatief tov je andere threads is.

Windows priority heb ik ook geprobeerd maar het haalde niet veel uit.

Toen ik hier nog eens over na dacht kon het ook nog zo zijn dat mijn threads op synchronized of waits zitten te wachten en het geheel eens met 3 en 4 threads gedraait maar ook dan kommen we 65-70 % heen. Deze terugval is misschien te verklaren uit de overschakeling tussen deze threads.

[momania]

Hoe lang 'draait' het algoritme eigenlijk?

Vergeet ook niet dat de JVM zelf het processor gebruik in de hand heeft/houd en ook nog wat optimalisatie slagen maakt, waardoor er misschien helemaal geen volle kracht nodig is.

[Soultaker]

Verwijderd schreef op dinsdag 09 januari 2007 @ 23:22:
Toen ik hier nog eens over na dacht kon het ook nog zo zijn dat mijn threads op synchronized of waits zitten te wachten [..]

Ik wilde het nét zeggen.

Probeer eerst eens een paar onafhankelijke CPU-intensieve threads te starten; als het goed is kom je dan wel in de buurt van 100% CPU-gebruik. Als dat zo is, is het inderdaad de synchronisatie die voorkomt dat je processor bezig blijft.

[Verwijderd]

hij runt met huidige invoer ongeveer 10 seconden.

[momania]

Da's niet zo lang, maar zou lang genoeg moeten zijn om flinke load te genereren.

Als je synchronisatie erin heb zitten, zou ik idd eerst daar eens naar kijken.

[Jaap-Jan]

Bij mij krijgt javaw zo'n 90% van de processortijd toebedeeld, de rest van de processortijd gaat op aan de andere processen. Oftewel, het lijkt erop dat de processor wel volledig belast wordt hier.

[Alarmnummer]

FallenAngel666 schreef op dinsdag 09 januari 2007 @ 23:11:
Je kan in Java de prioriteit van je threads hoger instellen, maar dat garandeerd niets.
Al geprobeerd om javaw via Windows taakbeheer een hogere prioriteit te geven?

Je kunt gerust je threads op de allerlaagste prioriteit instellen doordat deze threads alsnog draaien als er verder niets te doen valt.

[Alarmnummer]

Verwijderd schreef op dinsdag 09 januari 2007 @ 23:22:
Toen ik hier nog eens over na dacht kon het ook nog zo zijn dat mijn threads op synchronized of waits zitten te wachten en het geheel eens met 3 en 4 threads gedraait maar ook dan kommen we 65-70 % heen. Deze terugval is misschien te verklaren uit de overschakeling tussen deze threads.

Probeer zo kort mogelijk in kritieke secties rond te blijven hangen doordat je daar anders last van lock contention gaat krijgen (en dat kan zich dus uiten in het niet volledig benutten van de cpu's).

Verder is synchronisatie (dus het aanvragen/releasen van locks) al lang niet meer zo duur als het ooit was. Context switchen is met zo'n laag aantal werkende threads waarschijnlijk ook niet de reden van het snelheidsverlies. De tijd dat een context switch kost, is maar een fractie van een 'jiffy' (een periode dat een thread mag draaien), dus zo veel overhead heb je daar niet van. Alleen op het moment dat je een groot aantal actieve threads hebt, dan gaan de jiffies korter worden, en de overhead van de contextswitch groter.

Waar je op dit moment nog niet zo heel veel last van hebt (omdat je namelijk een shared l2 cache hebt) is cache invalidatie (dit is een gevolg van synchronisatie icm java memory model). Het gevolg van cache invalidatie is dat er veel vaker toegang nodig is tot het veel langzamere main memory. Dus op het moment dat we meer gescheiden caches gaan krijgen, zijn multicore systemen snellere geheugenbussen nodig omdat anders de caches niet snel genoeg gevuld kunnen worden, en dit heeft als gevolg dat cpu's moeten wachten.

[ Voor 42% gewijzigd door Alarmnummer op 10-01-2007 17:11 ]

[alx]

Bij te lage speedups ligt het meestal aan jezelf ; te lang in wait() en op synchronized blokken. Of dat idd zo is en waar dat zit is, kun je zien door je run even te profilen (optie -Xprof). Dan zie je zo per thread hoe lang er gewacht wordt.