Thread history

From Talk:Gilgalad
Viewing a history listing
Jump to navigation Jump to search
Time User Activity Comment
20:55, 21 June 2013 MN (talk | contribs) New reply created (Reply to Errors when minimized)
19:42, 21 June 2013 Skilgannon (talk | contribs) New reply created (Reply to Errors when minimized)
17:14, 21 June 2013 AW (talk | contribs) Comment text edited (typo)
17:14, 21 June 2013 AW (talk | contribs) New reply created (Reply to Errors when minimized)
16:26, 21 June 2013 Voidious (talk | contribs) New reply created (Reply to Errors when minimized)
10:56, 21 June 2013 Skilgannon (talk | contribs) New reply created (Reply to Errors when minimized)
20:19, 20 June 2013 MN (talk | contribs) New reply created (Reply to Errors when minimized)
15:34, 20 June 2013 AW (talk | contribs) New thread created  

Errors when minimized

I've noticed that Gilgalad will sometimes throw a lot of ArrayIndexOUtOfBounds exceptions at the start of the first round when I pause robocode, hit restart, minimize, and unpause from the "Gilgalad console" window. However, it never happens if I start the battle from robocode, and then minimize it. Also, I saw some strangely low scores against Raiko mini in local tests (one as low as 15%) which may be related. I'll try to test on different JVM's, OS's and machines in the next few days, but I was wondering if you had any idea why minimizing the robocode window would do this?

AW (talk)15:34, 20 June 2013

Minimizing the window puts the engine in max speed. Might affect skipped turn detection.

MN (talk)20:19, 20 June 2013

Yeah, speed is the only thing I can think of. You aren't doing any threading or anything like that, are you? Because it could be something like race conditions if you are. Where is the ArrayIndexOutOfBounds being thrown from? I suggest you do try/catch around all errors, and write them to disk so you can check them out later.

Also, avoid testing against Raiko (mini) if you can because it saves data. Rather test against RaikoMicro, or do something about that data-saving, like modifying Raiko or deleting the files each time.

Skilgannon (talk)10:56, 21 June 2013

Yeah, from experience I know the CPU being pushed will cause more skipped turns, though you get the impression it should be immune to that. I usually attribute it to the CPU measurement being inaccurate and the high load exacerbating it somehow. You'll also skip more turns against a CPU heavy opponent.

One interesting thing I've found with BerryBots is that when I'm drawing graphics, bots take about twice as much CPU time. I've guessed it has to do with memory or CPU cache misses increasing when it's switching between robot code and graphics code. I could imagine a similar change in cache behavior when a CPU starts experiencing high load - maybe the Robocode engine code is what stays cached in that case and so your bot takes longer. But I'm just speculating and don't really know that much about CPU cache behavior.

Voidious (talk)16:26, 21 June 2013

Well, I'm not entirely certain and I don't want to spread false information, so we'll just wait until Rednaxela fills us in...

Regarding my problem, it was indeed related to skipped turns. I have a record of the enemy's positions and I use it to check the wave intersection with the enemy robot after I retroactively set the bullet powers. Skipped turns caused me to miss the entries on some turns, resulting in the OutOfBoundsException.

But this led me to think of another question. In PIF guns, how do you deal with the end of a round. Do your logs just jump to the next round or do you keep separate logs for each round or what?

Thanks for the help!

AW (talk)17:14, 21 June 2013

Any PIFs that hit the end of the round I discard. I pull a bigger cluster than I need and just do the first N that work.

Skilgannon (talk)19:42, 21 June 2013

Keeping separate logs for each round is more accurate, but with bigger codesize as well.

MN (talk)20:55, 21 June 2013