Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
9.5 BarnesHut
Hallo,
nachdem meine parallelen Varianten nicht wirklich schneller werden als die Sequentielle hab ich mir mal die Kernauslastung bei der Ausführung angeschaut und festgestellt, dass auch bei der Sequentiellen Variante alle Kerne ausgelastet sind.
Liegt es nun daran, dass die JVM sich auf alle Kerne verteilt oder läuft da irgenderwas falsch?
Mal so zum Vergleich: Bei createTree braucht die Sequentielle Variante ca. 0.2 s für middle und 4.8 s für large…
ich hab das gleiche problem
Auch bei der sequentiellen Variante werden mehrere Threads erstellt (teils von der JVM, teils für das GUI), aber der Löwenanteil der Berechnungen sollte von einem Thread übernommen werden. Demnach sollte auch nur ein Kern voll ausgelastet sein. Ich habe die sequentielle Version nochmals im Huber-CIP laufen lassen, dort verhält es sich auch genauso. Könnte aber auch vom verwendeten System abhängen.
Habt ihr in der main()-Methode der BarnesHutImpl auch ein Objekt von BarnesHutImpl erzeugt? Wenn man die main()-Methode aus BarnesHutSeq kopiert, wird dort nämlich ein BarnesHutSeq-Objekt erzeugt, wodurch sich die Laufzeiten der beiden Versionen natürlich nicht unterscheiden. Ansonsten sollten sich die Laufzeiten schon unterscheiden.
ja hab die main angepasst, denke mal das es an meiner parallelisierung liegt.
habe nach einigem rumprobieren, jetzt die schnellsten ergebnisse mit einer queue zur arbeitsverteilung bei der createtree und einem forkjoinpool bei der adjustmassandposition.
vlt. einen tipp was ich noch versuchen sollte?
Hier nochmal ein paar Werte, wären die vom SpeedUp her in Ordnung:
middle: seq impl
create: 0,226s 0,308s
adjust: 0,034s 0,072s
compute: 0,792s 0,322s
middle: seq impl
create: 5,274s 4,271s
adjust: 0,402s 0,383s
compute: 12,822s 5,473s
Hat jemand einen Tipp, wie man createTree() schneller/besser bekommt?
Im Gegensatz zur sequentiellen Version ist die parallele Version bei uns noch richtig langsam.
Habe die addRek()-Methode jetzt auch schon in eine sequentielle Methode umgewandelt. Aber das Synchronisieren will nicht klappen.
java.lang.AssertionError: Called on leaf-node
at BarnesHut.getChildNodeOverParticleist mein größter Feind…
Bin gerade etwas ratlos 
Danke! 
Wie oft darf ich in einem recursiveTask in einem ForkJoinPool forken?
Geht das mehrmals oder nur 1x pro Task? (d.h. ist eine for(node i: nodelist){ myTask task = new myTask(i); task.fork(); moeglich? )
Oder muss ich nach jedem fork() erst join() aufrufen bevor ich erneut forken kann?
Du kannst von einem ForkJoinTask aus mehrere weitere ForkJoinTasks forken. Siehe zum Beispiel auch die Methode [m]invokeAll()[/m], die genau dies mit einer beliebigen Anzahl von ForkJoinTasks tut. Allerdings darfst du auf einem einzelnen ForkJoinTask-Objekt nicht mehrmals [m]fork()[/m] aufrufen.
1 Like
Hier mal meine Zeiten, jeweils für die ersten 4 Bilder des mittleren Tests, also n = 50.000
Seq
Par:
Wenn Bedarf ist kann ich auch noch für n = 500.000 posten.
ja bedarf währe da, auf welcher Hardware lief das ?
Thx
Bass
Das ist ein i5-4570K @3.6GHz, 4 Kerne 4 Threads.
Hier für n= 500.000:
Seq:
Par:
Vor allem der TreeForce speedup ist schon ganz nett xD
EDIT:
Sagt mal ist nur für mich die Webseite des Lehrstuhls und das EST nicht zu erreichen? Dauernd Zeitüberschreitung
thx,
ja ist auch down bei mir.
Bass
Kleiner Hinweis noch: Wenn man Zeitmessungen in Java durchführt, sollte man allerdings bedenken, dass zu Beginn der Code nur interpretiert wird und die JVM nach Bedarf heißen Code (d.h. Code, der hinreichend oft ausgeführt wird) kompiliert bzw. optimiert. Das bedeutet, dass die ersten Durchläufe bestimmt sind von Effekten, die wenig bis gar nicht von der eigenen Implementierung abhängen (sieht man im geposteten Beispiel schön an der deutlich höheren Zeit für den ersten Aufruf von [m]createTree()[/m]). Wenn man also Zeitmessungen (in Java) zu Vergleichszwecken nimmt, sollte man die ersten Durchläufe lieber ignorieren.
Müsste reichen, wenn es ein Team-Partner abgibt, oder?
ja 