Talk:RougeDC

Hey, do you copy thing from Template:Bot Page or using subst:? » Nat | Talk » 06:52, 19 May 2009 (UTC)

• Using subst:. I thought I'd try it, didn't get around to cleaning up after though :) --Rednaxela 07:15, 19 May 2009 (UTC)

Bad Results (willow)

Version "willow" may be throwing exceptions or possibly running out of memory. In addition to the battle you pointed out on the RR server talk page, there are other examples: [1], [2] (Simonton's client), [3] (Voidious), [4] (Rednaxela, no opponent bullet dmg). --Darkcanuck 21:12, 24 August 2009 (UTC)

It's for certain more memory efficient than the old version. Throwing exceptions is a possibility, but I don't see how and cannot reproduce this at all... If anyone sees it throw an exception it would be nice to hear about it... =\ --Rednaxela 21:23, 24 August 2009 (UTC)

I see this in my RoboRumble client:

Fighting battle 7 ... ags.rougedc.RougeDC willow,voidious.Dookious 1.573c
Preparing battle...
Exception in thread "Battle Thread" java.lang.OutOfMemoryError: Java heap space
	at java.io.ObjectOutputStream$BlockDataOutputStream.<init>(ObjectOutputStream.java:1711)
	at java.io.ObjectOutputStream.<init>(ObjectOutputStream.java:221)
	at robocode.util.ObjectCloner.deepCopy(Unknown Source)
	at robocode.robotpaint.Graphics2DProxy.copyOf(Unknown Source)
	at robocode.robotpaint.Graphics2DProxy.create(Unknown Source)
	at robocode.battle.snapshot.RobotSnapshot.<init>(Unknown Source)
	at robocode.battle.snapshot.TurnSnapshot.<init>(Unknown Source)
	at robocode.battle.Battle.finalizeTurn(Unknown Source)
	at robocode.battle.Battle.runTurn(Unknown Source)
	at robocode.battle.Battle.runRound(Unknown Source)
	at robocode.battle.Battle.run(Unknown Source)
	at java.lang.Thread.run(Thread.java:619)

Dookious uses its fair share of memory, so I can't squarely place the blame on RougeDC, but I don't recall ever seeing/hearing about this for Dooki before. My client is set to 512 MB. I'll try running some battles manually and hunting for exceptions later tonight. --Voidious 21:31, 24 August 2009 (UTC)

You don't think it could be something to do with your new tree? Maybe add something to the benchmark which monitors the maximum memory consumption of the trees as well... --Skilgannon 14:52, 25 August 2009 (UTC)

Monitoring the maximum memory usage would be difficult to do I think... however... running the benchmark in a profiler earlier indicated to me that it's memory usage was just as small as the Simonton and Voidious trees. There is only one way I can think of that RougeDC uses more memory than before: It has a 'time' segment, and it's ever-increasing nature would likely cause any kd-tree to become ridiculously unbalanced given enough time. I'm quite doubtful that is the issue though, since this didn't occur with the old kd-tree which branched in a very similar way and was far less efficient in many ways. --Rednaxela 15:09, 25 August 2009 (UTC)

(double edit conflicts) My last 100 repetitions test run with default heap space (i.e. not -Xmx) so the usage should be under 128M. Red, I think you should recorded the searches/adds request from RougeDC vs. Dookious and run the benchmark again... » Nat | Talk » 15:13, 25 August 2009 (UTC)

Hmm... well... running RougeDC vs Dookious, and running a java memory profiler indicates that the Kd-Tree is not a significant memory user in the slightest, and that the big memory users are some other things in Dookious and RougeDC that have never changed. So... 1) I can't duplicate running out of memory at 512MB like Voidious had, and 2) Even if it were running out of memory, it wouldn't be due to the new Kd-Tree. So unless these bad results were flukes that could have just as easily happened to the old RougeDC, something is very very weird... --Rednaxela 06:47, 28 August 2009 (UTC)