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.
8.5 GameOfLife
Hallo,
hab bisher lediglich die sequentielle Implementierung gemacht, habe jedoch schon ein Problem bei 2 der vielen Tests.
testRPentomino läuft glatt.
testRPentomino2 & testRPentomino3 leider nicht → java.lang.AssertionError: expected:<116> but was:<6>
Probiere nun schon ewig rum und komme nicht drauf woran dies liegen könnte. Einziger Unterschied in den Tests scheint ja die displayUpdateRate zu sein.
Grüße
Genau. Die displayUpdateRate bestimmt aber, wie oft evolve aufgerufen wird. In testRPentomino wird evolve 1103 mal aufgerufen, in testRPentomino2 nur 3 mal, in testRPentomino3 nur einmal.
Berechnest du in evolve die angegebenen Generationen?
Ich nehme an, du arbeitest immer mit einer Kopie des Spielfeldes? Der Fehlercode kann davon kommen, dass du deine Aktualisierung des alten Spielfeldes mit der Kopie fehlerhaft ist. Aktualisierst du, indem du mit einer for-Schleife die Werte aus deiner Kopie in dein altes Spielfeld wieder einfügst oder biegst du die Zeiger um?
Edit: Als Test könntest du einfach mal jeden Wert des alten Spielfeldes per for-Schleife mit dem neuen Wert der Kopie aktualisieren. Das ist zwar keine schöne Lösung sollte aber funktionieren 
Jop… sowas in der Art war es. War vielleicht auch etwas schnell nach Hilfe geschrien :P. Aber nun ist wenigstens der Thread für die Aufgabe schon mal da^^ Danke für euere Hilfe.
Merke nur nicht wirklich nen SpeedUp bei mehreren Threads. Da dürfte irgendwas verklemmt sein, frage mich nur was, mehr als ein CyclicBarrier benötigt man ja nicht. Meine sequentielle Version ist schneller als jede Parallele.
Jemand Lust mal seine Zeiten zu posten?
Bin mal wieder zu faul im CIP zu testen 
, aber auf meinem Rechner:
RPentomino3:
Seq: 2.89 s
2 Threads: 1.24 s
3 Threads: 1.07 s
4 Threads: 0.92 s
5 Threads: 1.13 s
6 Threads: 0.99 s
7 Threads: 1.05 s
8 Threads: 1.13 s
Acorn:
Seq: 14.19 s
8 Threads: 3.56 s
Edit:
Zur Erklärung:
Die Anzahl der Speicherzugriffe ist hoch im Vergleich zur geleisteten Rechenarbeit,
dadurch ist der Speedup sehr niedrig.
Hmm…
Habe da scheinbar irgendwo noch ein Problem drin. Ich habe ein CyclicBarrier benutzt an dem 2 mal gewartet wird (analog zu VL Folie 08-13).
Vorhin liefen die Tests mal fehlerfrei durch. Nun hackt es wieder an dem Acorn Test ( SpeedUp > 1.5).
Attachment:
Bildschirmfoto 2015-06-10 um 18.46.31.png: https://fsi.cs.fau.de/unb-attachments/post_140940/Bildschirmfoto 2015-06-10 um 18.46.31.png
Wenn mans geschickt macht, reicht einmal warten,
allerdings kostet das höchstens ein paar Millisekunden.
Kopierst du das Array in jeder Generation? Wenn ja,
versuchs mal nur mit 2 Arrays, die du zum Beispiel in configure initialisierst.
Ich versteh nicht so ganz was die cellDisplaySize ist? Ist das die Größe für ne grafische Darstellung oder ist das die Größe eines Feldes im Array?
cellDisplaySize ist die Anzahl der Pixel einer Zelle bei der grafischen Darstellung.
Ihr braucht das also in eurem Code gar nicht ;).
hey,
auch nochmal zur parallelen Ausführung…die Tests laufen bei mir geschmeidig durch, aber bei Blinker, Glider, Pentomino, DieHard gibts Probleme mit den Arrayeinträgen. Bsp Blinker : arrays first differed at element [1][2]; expected:<1> but was:<0>.
Oder bei Pentomino : java.lang.AssertionError: expected:<116> but was:<5>
Fehler in der Berechnung müssten ja ausscheiden, sonst wären die anderen Tests nicht erfolgreich. Und Threads kommen sich ja eigentlich auch nicht in die Quere, was auch in den anderen Tests bemerkbar machen würde…
Hi, versuch mal in deinem Runnable/ Thread/… bei jeder neuen Generation das Spielfeld-Array (sowie das „Zukunftsarray“) auf das aus deinem GameOfLifePar zu setzen, also die Referenz zu aktualisieren.
Bei den Tests die funktionieren verändern sich glaube ich die Zellen nie, deshalb gibt es da auch kein Problem.
Dürfen die Threads schon die erste Generation berechnen und auf den Befehl evolve ihr Ergebnis schreiben?
Oder darf erst angefangen werden zu rechnen wenn der Befehl evolve ausgeführt wird?
Vielleicht ist meine Variante auch Wirrwarr oder blöd implementiert…jedenfalls, hab ich evolve hergenommen um die Threads loslaufen zu lassen bzw. dem executor Futter zu geben. Also fängt die Berechnung an wenn evolve aufgerufen wird…
Wieso sollten die Threads denn die erste Generation schon berechnen, wenn compute() evolve() aufruft um die eigentlich Berechnung durchzuführen und dessen Ergebnis zu bekommen?
Ich hab auch ein wunderbares Problem:
Mein Code compilt daheim wunderbar, nur lade ich ihn im EST hoch, bekomme ich einen Totenkopf.
Schon probiert:
- Im CIP compilet es wunderbar
- Keine Packages
- Included wurde nur die CyclicBarrier
Liste aller 11 Totenkoepfe:
9x GameOfLifePar fehlt
1x public Klasse in der Datei HashLife.java ist falsch benannt
1x Zugriff auf ein Feld, dass nicht existiert
Sind also alles korrekte Fehlermeldungen ;).