SWT[5]#3
-
- Beiträge: 8
- Registriert: Mo 3. Nov 2008, 20:30
SWT[5]#3
Hallo zusammen,
um den Start womöglich etwas zu erleichtern, hier ein kurzes HowTo, wie mit dem Jar-File "args4j-2.0.9.jar" umzugehen ist und die Start.java wieder "startbar" wird:
Gruß
Alex
um den Start womöglich etwas zu erleichtern, hier ein kurzes HowTo, wie mit dem Jar-File "args4j-2.0.9.jar" umzugehen ist und die Start.java wieder "startbar" wird:
Gruß
Alex
Re: SWT[5]#3
So, ich hab das Programm mal geschrieben, allerdings nen seltsames Problem mit ner Exception. Ich hab' mir zunächst eine neue Klasse gebaut, die alle parallelen stuff tut. Dann bin ich hingegangen, hab mir ne innerClass gebastelt, die von Threads erbt. Beim starten der mandelbrot.Start wird zuerst ein Array mit der Anzahl an gewünschten Threads angelegt und schonmal mit den Threadobjekten initialisiert, sodass später nur noch die Werte über Setter gesetzt werden müssen. Sind allerdings alle Threads in-use, so hab' ich ne Lösung gefunden indem ich einfach per while-Schleife auf thread[x].isAlive() prüfe, ob der Thread noch rennt oder nicht, falls ja, mach das halt solange bis einer frei wird. Und dann wirfts auch schon bald ne Exception. Einmal "befüllen" geht, danach aber weitere Threads drauf laufen lassen wirft
Irgendwo hab' ich gelesen, dass das ein Java-Bug sei, hat vll. noch einer nen ähnliches Problem oder eine bessere Lösung?
Code: Alles auswählen
Exception in thread "AWT-EventQueue-0"
Re: SWT[5]#3
Das is kein Bug in Java, das deutet schwer darauf hin, dass du dein Array nicht vollständig befüllt hast.
Im übrigen empfehle ich dir einmal einen Blick in das Package java.util.concurrent (Java API Doku und so...), dort gibt es eine Menge kleiner Helferlein, die dir das Arbeiten auf blanken Threads ersparen (Stichwort: Executor, ExecutorService, Threadpools) etc.
Das Problem ist: Dein "compute()" wird vom AWT-Event-Dispatcher aufgerufen - ergo wird deine Exception auch von diesem Thread entsprechend behandelt. Das gestaltet das Debugging leider etwas schwieriger.
mfG
Markus
Im übrigen empfehle ich dir einmal einen Blick in das Package java.util.concurrent (Java API Doku und so...), dort gibt es eine Menge kleiner Helferlein, die dir das Arbeiten auf blanken Threads ersparen (Stichwort: Executor, ExecutorService, Threadpools) etc.
Das Problem ist: Dein "compute()" wird vom AWT-Event-Dispatcher aufgerufen - ergo wird deine Exception auch von diesem Thread entsprechend behandelt. Das gestaltet das Debugging leider etwas schwieriger.
mfG
Markus
Re: SWT[5]#3
Wer keine Lust hat, das Programm 180 mal mit verschiedenen Parametern aufzurufen, hier ein Bash-Script von mir, das das automatisch macht.
Es wird eine Tabelle in diesem Format ausgegeben:
Lässt sich dann ganz einfach in OOCalc per Copy&Paste einfügen oder Importieren (Semikolon als Trenner verwenden). Dann noch Beschriftung in die Spalten darüber und zeichnen lassen.
In Excel gehts wohl wahrscheinlich ähnlich.
Es wird eine Tabelle in diesem Format ausgegeben:
Code: Alles auswählen
sequentiell size 100;parallel 2 size 100;parallel 3 size 100;...
sequentiell size 200;parallel 2 size 200;parallel 3 size 200;...
...
Code: Alles auswählen
#!/bin/bash
if [ $# -lt 1 ]; then
echo -e "$0 erwartet die jar-Datei als Parameter."
else
SIZE=100
while [ $SIZE -le 2000 ]; do
THREADS=2
java -jar $1 -w -s $SIZE
while [ $THREADS -le 512 ]; do
echo -n ";"
java -jar $1 -w -s $SIZE -p -t $THREADS
let THREADS=THREADS*2
done
let SIZE=SIZE+100
echo -e
done
fi
In Excel gehts wohl wahrscheinlich ähnlich.
Zuletzt geändert von salami am Mi 24. Jun 2009, 12:28, insgesamt 1-mal geändert.
Re: SWT[5]#3
Hallo liebe Kollegen,
Ich würde sagen, ich bin fertig mit der Aufgabe. Allerdings sieht aber das Ergebniss seltsam aus:
Click mich für ein Screenshot
Ich habe alle Tests zehnmal durchgeführt, und für die Diagrammen immer den Durchschnitt genommen. Es fallen aber bei mir (fast) alle Laufzeiten beim parallelen Algorithmus zusammen, unabhängig von der Anzahl von Threads. Ich habe ja zwei CPU-Kerne, und würde erwarten, dass es bei 2 Threads am schnellsten ist, und immer langsamer wird je mehr Threads dazukommen. Trotzdem wird es NUR für genau 8 Threads langsamer als mit 2,4, 16, 32 usw., und scheinbar kosten auch 512 kaum mehr Overhead als etwa 16 O_o
Hat jemand eine Idee, ob da was falsch ist, oder evtl. dasselbe Ergebnis?
Ich würde sagen, ich bin fertig mit der Aufgabe. Allerdings sieht aber das Ergebniss seltsam aus:
Click mich für ein Screenshot
Ich habe alle Tests zehnmal durchgeführt, und für die Diagrammen immer den Durchschnitt genommen. Es fallen aber bei mir (fast) alle Laufzeiten beim parallelen Algorithmus zusammen, unabhängig von der Anzahl von Threads. Ich habe ja zwei CPU-Kerne, und würde erwarten, dass es bei 2 Threads am schnellsten ist, und immer langsamer wird je mehr Threads dazukommen. Trotzdem wird es NUR für genau 8 Threads langsamer als mit 2,4, 16, 32 usw., und scheinbar kosten auch 512 kaum mehr Overhead als etwa 16 O_o
Hat jemand eine Idee, ob da was falsch ist, oder evtl. dasselbe Ergebnis?
When we say that two functions are almost always used together, we should remember that "almost" is a euphemism for "not."
-- David L. Parnas, "Designing Software for Ease of Extension and Contraction"
-- David L. Parnas, "Designing Software for Ease of Extension and Contraction"
Re: SWT[5]#3
Wie kann ich meinen Threadpool warten lassen bis alle Threads fertig sind? Hab das bis jetzt so:markusj hat geschrieben:... einen Blick in das Package java.util.concurrent (Java API Doku und so...), dort gibt es eine Menge kleiner Helferlein, die dir das Arbeiten auf blanken Threads ersparen (Stichwort: Executor, ExecutorService, Threadpools) etc.
Code: Alles auswählen
threadPool.shutdown();
while (!threadPool.isTerminated()) { /*idle */ }
return result;
Re: SWT[5]#3
graph scriptchen
http://tmp.kanojo.de/test.sh
http://tmp.kanojo.de/plot1.gnuplot
sind zwar kacke und einfach aber tun so n bissl ... viel spaß
http://tmp.kanojo.de/test.sh
http://tmp.kanojo.de/plot1.gnuplot
sind zwar kacke und einfach aber tun so n bissl ... viel spaß
Re: SWT[5]#3
Tankwart: awaitTermination lautet das Schlüsselwort - du darfst da gerne beliebig große Zeitspannen reinstopfen, das reicht vollkommen
Und dann halt nach dem Aufwachen immer schön prüfen ob der Pool tatsächlich fertig ist oder nur ein Jahrzehnt verstrichen ist ...
mfG
Markus
Und dann halt nach dem Aufwachen immer schön prüfen ob der Pool tatsächlich fertig ist oder nur ein Jahrzehnt verstrichen ist ...
mfG
Markus
Re: SWT[5]#3
Hatte ich ausprobiert, aber irgendwas hab ich da wohl falsch gemacht, jetzt gehts. Mercimarkusj hat geschrieben:Tankwart: awaitTermination lautet das Schlüsselwort
Re: SWT[5]#3
Liege ich richtig in der Annahme, dass ihr das ganze ohne eine Barrier gemacht habt und nur mit Executors?