| Autor |
Mitteilung |
roland
registriert
|
Gesendet: 25 Jun 2005 02:49:13
Hallo Ihrs!
Wir haben heute die Ergebnisse des ersten Teils der Endrunde ausgewertet und leider waren einige Timeouts drin. Es scheint wol wider mal am GC zu liegen. Weil das ein Java-internes Problem ist, werden wir alle Timeoutspiele morgen noch mal wiederholen.
Deswegen gibt es heute auch noch keine Ergebnisse, sondern wahrscheinlich erst am Sonntag.
Gruß,
Roland
|
_ZK666_
registriert
|
Gesendet: 25 Jun 2005 13:17:22
dumm nur für die leute, die nen time-out-abfang-mechanismus drinne haben und ihre schlange ztwar nicht rausfliegt, dafür aber nur dummes zeugs macht...
na egal.
bye-ZK666
|
linap
registriert
|
Gesendet: 25 Jun 2005 14:44:17
Gibt es irgendwelche konkreten Anhaltspunkte, dass der GC dran Schuld ist? Nur weil Timeouts vorkommen, muss das ja nicht zwangsläufig am GC liegen...
|
tthuem
registriert
|
Gesendet: 25 Jun 2005 15:19:29
@zk666
dort fliegen auch leute raus, die einen "time-out-abfang-mechanismus" drinne haben! wenn sich der gc dazwischen hängt dauert plötzlich eine einfache addition 200ms oä!!!
|
pantufle
registriert
|
Gesendet: 25 Jun 2005 16:59:06
Nur so eine Vermutung ...
es spielen jetzt sehr viele top-teams gegeneinader, die z.T. sehr viel Ressourcen verbrauchen. Es ist klar, das in Spielen wo auch schwächere (ressourcenärmere) Gegner teilnehmen insgesamt eine bessere Performance zu beobachten sein sollte ...
|
_ZK666_
registriert
|
Gesendet: 25 Jun 2005 17:27:19
jo
@pantufle, nur egal ob "dumm" oder "schlau", jedem SPIELER stehen 100ms zur verfügung, nicht jedem GAMECYCLE.
@thomas: ist ja richtig was du da schreibst, trotz allem hab ich sehen können, dass zumindest unsere "abfang"-methode anscheinend funktioniert hat, weil unsere snake dann z.b. in die Exit-sackgasse reingefahren ist, obwohl es bis zu dem punkt, wo die exits geöffnet werden als absolute mauer markiert werden. somit eigentlich nie ansteuerbar, es sei denn unsere snake hat nicht mehr genug zeit und geht stur geradeaus in ihr verderben, weil die zeit nicht mehr stimmt. kommt halt auch darauf an, mit welchen algorithmus die methode msLeft() ausgenutzt wird. wir z.B. springen raus, wenn msLeft()<20% von maximaltime ist, also noch genug zeit zur verfügung wäre. somit ist es nicht ersichtlich, ob wir nen timeout bekommen hätten oder ob nicht...
na egal, macht man. wird schon schief gehn 
bye-ZK666
|
pantufle
registriert
|
Gesendet: 25 Jun 2005 17:44:37
@_zk666_
wenn ich das richtig sehe, werden ja die zeiten recht großzügig ermittelt ... die gamecycle-zeiten werden doch im Durchschnitt genommen ... wenn man nun konstant über 100 ms (jeden einzelnen Gamecycle) hat (oder scharf an der Grenze spielt) kann es nunmal passieren das timeouts geschmissen werden falls der Rechner mal nicht 100% geben kann ...
|
_ZK666_
registriert
|
Gesendet: 25 Jun 2005 20:58:20
tja keine ahnung. ich denk mal, das weiß nur der programmierer von sneady selbst, wie das alles gehandhabt wird.
bye-ZK666
|
tthuem
registriert
|
Gesendet: 25 Jun 2005 21:18:28
@zk666
meine schlange nutzt genau die gleiche abbruchbedingung wie eure, trotzdem hatte ich in der hauptrunde insgesamt 26 timeouts. leider ist das in java alles etwas schlecht durchschaubar, woran es nun genau liegt.
|
linap
registriert
|
Gesendet: 25 Jun 2005 21:49:04
Das Problem besteht doch nur darin, dass die Systemzeituhr und die den Schlangen zur Verfügung stehende Rechenzeit divergieren kann. Da der GC in der Standardkonfiguration alle laufenden Threads der JVM unterbricht, wäre es möglich die den Schlangen tatsächlich zur Verfügung stehende Zeit zu ermitteln, um nicht auf anderweitige Schätzungen zurückgreifen zu müssen. Für solche Änderungen - sofern möglich - ist es jetzt wohl zu spät und es muss eine andere Lösung für das elende Timeout-Problem gefunden werden...
|
