Müllabfuhr

. 1 . 2 . >>

Autor	Mitteilung
linap registriert	Gesendet: 21 Mar 2005 14:25:26 Hi Habt ihr schon mal drüber nachgedacht, die Überprüfung des Speicherbedarfs im Tournament-Modus anders zu lösen? Der bisherige Weg hat meines Erachtens den Nachteil, dass sehr viel Zeit für den Garbage Collector drauf geht (bei mir mindestens 100ms pro gc()) und Rechenroutinen dann mehr Zeit fressen, zumindest was eure Laufzeitmessung betrifft. Alternativ könnte man doch bei der JVM über "-Xmx" den Arbeitsspeicher hart begrenzen und nur bei out-of-memory eine Überprüfung der einzelnen Schlangen durchführen, wobei der Garbage Collector rundenweise aufgerufen wird... so long, Thomas.
roland registriert	Gesendet: 22 Mar 2005 00:37:31 Hi Thomas! Dein Vorschlag hat 2 nachteile. 1. Der Spieler, der eine out of memory exception wirft, hätte probleme seinen zug zu beenden. Seine internen Daten sind anders, seine berechnung wurde nicht beendet, er hat keine kontrolle was passiert. Wir müssten also vor jedem Zug eine komplette kopie anfertigen um sicher zu stellen, dass er keinen Nachteil von der OOM - Exception hat. 2. Wenn die JVM wirklich OOM wirft, dann können wir nicht mehr überprüfen wie viel Speicher die einzelnen Spieler verbrauchen. Denn man kann das nicht so einfach messen. Um herauszufinden wie viel speicher ein Spieler benötigt, muss er komplett serialisiert werden. Das heißt seine komplette INstanzmit allen abhängigen Daten wird in ein byte array kopiert. Diesen Vorgang nennt man serialisieren. Den array könnte man nun in einer datei abspeichern und zu einem späteren zeitpunkt wieder laden. Aber wir messen lediglich die Länge um fest zu stellen wie viel Speicher er benutzt. Daraus folgt dann auch, dass wir selbst für die Kontrolle viel Speicher brauchen, und dieser muss ja auch wieder frei gegeben werden. Deswegend er GC- aufruf. damit das nicht während eurer berechnung passiert. Gruß, Roland
linap registriert	Gesendet: 22 Mar 2005 11:28:00 Wenn ich dich richtig verstehe, ist es also eine subjektive Einbildung von mir, dass meine Schlange ge-time-killed wird, wenn gleichzeitig der Memory-Check im Hintergrund läuft. An den Speicherbedarf des Serialisierens an sich habe ich gar nicht gedacht... Aber um diesen und den anderen ins Feld gebrachten Nachteil zu umgehen, könnte man ja theoretisch eine Client/Server-Architektur auf die Beine stellen, in der jede Schlange in einer eigenen JVM läuft Kann mir aber vorstellen, dass dabei eventuell die Kommunikation der (Zeit-)Flaschenhals würde und es vor allem überhaupt nicht in euer bisheriges, sehr gelungenes Konzept passte. so long.
roland registriert	Gesendet: 22 Mar 2005 15:18:37 der memory check läuft nicht zur gleichen Zeit wie die spieler überlegen. das einzige was sein kann ist, dass der GC einfach noch so lange bruacht, dass es in die berechnung der schlangen mit hineinreicht. das werd ich mal genauer untersuchen und wenn es denn so ist, dann müssen wir die wartezeit für den GC erhöhen.. macht zwar das spiel langsamer dann, aber was hilfts.. immer noch besser als wenn er unkontroliert anfängt zu rödeln wenn ein spieler überlegt... Gruß, Roland
linap registriert	Gesendet: 22 Mar 2005 16:47:00 Alles klar, danke. Wenn ihr eine Art Timeout für den GC hart gecodet habt, mag es sein, dass es in Ausnahmefällen Probleme damit gibt. Mein Testrechner ist relativ langsam (400 Megahertzen), so dass das Phänomen vielleicht von der Lahmheit des GC bei meinem Rechner stammt. so long.
roland registriert	Gesendet: 23 Mar 2005 10:58:14 wir arbeiten daran, 400MHz is kein grund warum es nicht funktionieren sollte.
Strati registriert	Gesendet: 23 Mar 2005 12:53:07 Hmm interessant, hat alles leider nur ein Problem man kann nicht kontrollieren wann der GC zuschlaegt, denn man fordert "Ihn" ja nur auf er soll Speicher freigeben, aber wann er das tut kann der Programmierer nicht beeinflussen. Von daher kann es unter Umstaenden bei langsameren Rechnern zu den oben genannten Problemen kommen! Die VM nimmt im uebrigen in der Standardkonfiguration feste 64 MB. Wenn ein Programm mehr moechte fliegt eine nette Exception. Also liegt es in den Haenden des Programmierers sparsam mit dem Speicher umzugehen und so zu programmieren, dass der GC nicht zu oft aufgerufen werden muss. Was die Sache mit der Client/Server-Architektur betrifft, ich finde das ist doch arg uebertrieben fuer dieses Problem? Ich nehme auch keine Crow fuer ein "Hello World" - Programm. :-D Schliesslich gab es Snake auch schon auf Amiga, Handys und in QBasic auf 286/386er Rechner... Gruss Strati
larsonmars Admin	Gesendet: 23 Mar 2005 13:13:47 Tja Strati...die Zeiten ändern sich...Wir verstehn uns
schnueptus registriert	Gesendet: 23 Mar 2005 14:53:01 naja sneady für das handy umschreiben wäre durch aus ne überlegung wert, vielleicht nicht 1:1 aber man kann ja kleinere levels machen und nur mit höchsten 4gegnern! Ich meine die Handys sind ja leistungsfähig (meins hat ein intel mit 104mhz und kann java, aber halt ein kleineres display) und die aktuelle generation haben 400mhz und 32mb ram (ich träume schon von einen neuen handy, wenn ich mein vertrag verlängere, mal kucken) Naja aber es geht ja eigendlich drum das man das letzte stück rechenleistung rausholt, zumindest versuchen Linap und ich das für unsere Schlange, wobei wir nicht wissen ob es für das UndergroundTunierr reicht! Aber wollte ja jemand mit genetic programming arbeiten und da ist dann vielleicht das doch ein ansatz oder so ... @linap: wenn du dann wieder in MD bist, kannst du uns mit deinen Rechner hier wieder alle auslachen g (naja, man sollte sagen, das er sonst damit sehr bescheiden ist)
Baschan registriert	Gesendet: 23 Mar 2005 17:34:27 naja, ich denke nich, das unbedingt so großes interesse daran besteht, sneady fürs handy umzuschreiben, auch wenn die handys leistungsmäßig ausreichend sind dafür.

. 1 . 2 . >>

Um einen Eintrag zu schreiben müsst ihr euch als Nutzer des snEADy-iBoards registrieren!