Archived talk:WeeksOnEnd 20090522

WeeksOnEnd Sub-pages:

WeeksOnEnd - Version History - Archived Talk 20090522

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

A new 1v1 MiniBot by Simonton that was his ticket to The2000Club/Mini. Come on, share all your secrets with us! -- Voidious

Oh, no, well, I mean, I couldn't. I'm just too shy. Ok, well, you talked me into it :).

---

Well, I now have 39 free bytes on this beast. Any ideas? It's not enough for what I really wanted to try, so who knows what would get me a few more points? A segment to wave surfing other than lateral velocity? A segment to the pattern matcher? I've been thinking of taking up a few bytes for a little different firepower choice. Whaddya think? -- Simonton

Hey, how about some nify colors! :P --Chase-san

Can't there be something more productive? Oh, and, make that 44 bytes. -- Simonton

I'd say segment on distance in the surfing, I segment on LateralVelocity and distance. I segmented on wall distance for a while, too, but it actually gained rating points (and saved bytes) to remove it. A little bullet power management is worth a few points, too, though I haven't managed to tweak more points out of it beyond my initial code for it. Not sure how you manage your distancing, but with Komarious I've found it pays big (like way more than I'd first think, intuitively) to move away from the enemy at all times. I've basically got 20 bytes free in Komarious if I remove the colors, but I just can't find anything worth using them for... -- Voidious

I tried removing the distance segment in my surfing and it cost me a few points. Now you try adding a distance segment =) -- Voidious

Ha! Easy for you to say. Komarious runs 1000 battles in just like a few hours. It takes me over 2 days! I know, I know. It's my own fault. -- Simonton

I would say to improve on which ever one you think is more important: MovementOrTargeting --Starrynte

Yes, that would be the task :). I'm not really so concerned which I improve, as much as how to improve it! I was more hopeful for version 1.4. :( -- Simonton

Ok, ok. So I didn't try putting in a distance segment yet. But start to think bigger, because I was de-codesize-ing, and now I have 117 bytes to play with. So, any great ideas with that in mind? -- Simonton

You could try something like adding anti-PM stuff to your movement (Not sure how to do that myself), the MusashiTrick, or maybe more segments to your surfing? --Nfwu

Funny you should mention it ... I was experimenting with anti-PM just last night. Haven't decided if it's going to help yet. Or if I can squeeze down my computation time enough to make it fit every turn. I'm nervous about adding segments to surfing, though ... I want to keep it agile & adaptable ... Oh, and the MusashiTrick just happened to be built into the wave surfing. --Simonton

A score of 2110.03 in the mini at 101 battles, Wow lets see if it stays! --Chase-san

I never trust ratings until the tank has faced every other bot - WeeksOnEnd 1.8 is actually behind 1.7 in a by-bot comparison. (I check the Comparison page, paste it into Excel, and sum the diffs.) That's only ~90 pairings and not many battles, though, so we still need to wait and see. ;) -- Voidious

Still impressive. --Chase-san

Thank you for the optimism, Chase. Voidious, we'll see if this race needs to continue soon enough. I just got done working on the rumble client. It now can run a focused competitor, so I'm going to set it to work on my home machine and go to bed. (Until now I was only running it on my machine at work. 2 is better than 1.) Sometime tomorrow you'll see a big jump in the battles fought for WeeksOnEnd, then we should have our answer. :) Good night. -- Simonton

Well, my money's on you to win this race ;), and WeeksOnEnd itself is absolutely "impressive". I was just saying that an interim rating isn't really that meaningful - as of now, 1.7 is your most impressive release, IMO. If 1.7 had only the same pairings as 1.8 has right now, it would have a higher rating than 1.8 does now. -- Voidious

I just realized something about WeeksOnEnd in the RoboRumble, though I'm not sure of any reasonable "solution" to it. By running all your battles on a single client, you may be at a disadvantage. Any bot that saves data does better if it runs multiple battles from the same client vs a given bot; since your bot doesn't save data (right?), it gets no advantage from multiple battles on the same client, but bots that save data are getting an extra advantage against it. For other bots (like Komarious), their battles are distributed across multiple clients, so the odds are less that any bot will get 2 battles against it on the same client.

Like I said, I'm not really sure how you can deal with this fairly - if you deleted your opponents' save data before each match, that would be kinda cheap, but they are definitely getting the most of their saved data in your current RR@Home client setup. There aren't nearly as many MiniBots that save data, luckily, so at least most of the effect is probably in the General rumble. But I just wanted to share the thought with ya.

-- Voidious

On the other hand, if WeeksOnEnd is a relatively slow bot, it may be at an advantage to do all its battles on a client that probably has an increased cpu constant, where if it were distributed, some clients might let it skip more turns :-) In either case, maybe those 50 bytes can find a way to make WeeksOnEnd's memory problems improve. -- Kawigi

Voidious: that is true. I never thought of that. Well - I should pay some price for bending the rules so much! :) Kawigi: unfortunetely it would take a lot more than 50 bytes to fix that. :(. Maybe when LifelongObsession comes out .... :/ -- Simonton

Hey man, do you have your client reporting some results only for the mini rumble? I noticed that WeeksOnEnd 1.9 has far more battles in the mini rumble than in the general rumble, which seems theoretically impossible... Any idea what's up with that? -- Voidious

Wow - that does seem theoretically impossible. I didn't notice that? I'll have to look at the mods I made to my client to run focused competitors offline. But what would cause the battles to be counted in the mini rumble but not in the general rumble? Must be because I replaced the "RUNONLY" property with the substring to match for focused competitors?? (In this case, "Week"). Can someone tell me? I wonder if any of the results I've been seeing in the mini/micro rumble are affected by this (for WeeklongObsession, too)? -- Simonton

Codewise, I'm not sure exactly how it's possible, but I know that it uploads a result once for each rumble it's supposed to be in. If it's not uploading 2 results for each WeeksOnEnd battle (like "Uloading WeeksOnEnd vs soandso..."), it's only uploading them to 1 rumble. Not really that big a deal, but something to investigate for sure. -- Voidious

---

Suggestion: if you add this to WeeksOnEnd, does it stop "leaking"?

public void onWin(WinEvent e){onEnd();}
public void onDeath(DeathEvent e){onEnd();}
public void onEnd()
{
	if (getRoundNum() == getNumRounds()-1)
		patterns = null;
}

It seems to work for me. I ran a series of 100-round battles with Shiz (just because I know it uses almost no memory that it might leak itself), and it seems to not allow the memory usage to blow up. If you have 20 or so bytes to spare, perhaps using it for this might be worthwhile :-) (still, if it's a bug in Robocode, we should also investigate that). -- Kawigi

Wow, that's very interesting. I'll try it. But if that is the case, it should most definitly be considered a bug. But then, why wouldn't it have come up with any other other bots? Has no one else really ever developed a memory hog? I do have 20 bytes to spare, I *think*, but it would be at the expense of some execution speed-up code, and I think it would skip some turns. At any rate, WeeklongObsession *definitely* does not have 20 bytes to spare. I'm trying to find one byte to squeeze out of it anywhere so I can release the next version. -- Simonton

Handling onBulletHitBullet made a big difference? I do it in Dookious, of course, but I find it really hard to believe it makes that much of a difference. I will look into it now, though. :) -- Voidious

:) -- Simonton

Sure enough, Kawigi, that completely takes care of the problem. Somewhere in robocode it is not setting something to null, then, apparently. It would be awesome if that got fixed and I could let you all run battles for me ;). But then, I guess it would take time for any new version to work its way into rumble clients ... -- Simonton

Fnl has been very responsive about updating Robocode, so I bet he can figure it out. Maybe you should summarize the issue on the Robocode page so that he definitely is aware of it. My rumble clients iterate every 10 battles, so they check for new bots and download them every few minutes... Your bots would definitely process faster if we were all running them. Seems like I see 3-4 people total processing battles whenever I check that uploaders script recently, and sometimes I'm running more than one client. -- Voidious

I will do that. But even if FNL updates robocode, it wouldn't work unless everyone running the client updated. One person running an old version would out-of-memory and my score would suffer drastically. -- Simonton

It is possible to let Robocode clean up the memory used by robots. But it is tricky. As far as I remember, the robot instances (objects) are created and destroyed for each battle. This way all memory used by a robot should automatically be cleaned up. But if a robot uses one or more static member fields, then this is a problem. The static variables are not set to null automatically it Java, and Robocode does not do this with a very good reason. Many robots uses static variables to maintain a structure or the alike from battle to battle. If I explicitly set the static member variables to null on all robots after each battle, then these structures will be lost, and Robocode would break compability with legacy robots. I you guys have a nice solution for it, when I will gladly implement it. :-) --Fnl

Ok, I need to learn the proper terminology. The issues isn't beteen each battle, then, but between each ... uh ... match? You know, like WeeksOnEnd could fight another robot, then 2 completely other bots could fight, then if WeeksOnEnd gets fight again, I'll have memory issues. -- Simonton

I think the 'accepted' terms are: fighting until one bot is left over = round. A normal RR@Home battle consists of 35 rounds. For several challenges a battle consists of 500 rounds. The static member fields Fnl is mentioning are (should) only be used within one battle. If someone needs to keep things between battles, (s)he must write it to file. If someone wants to keep things between rounds (and every wavesurfer, GF-gun and PM-gun needs that), the data can be put in static variables. -- GrubbmGait

You could just clean up the thread after the battle is over (e.g. after all the rounds have run), that would remove the data used by the static variables, and it might be able to be done without massive rewiring, let me take a look through the cvs. --Chase-san

Okay, looking through the CVS, I stumbled upon this in the robocode.battle.Battle.java. On line 218, is the line while (!abortBattles && roundNum < numRounds), thus it runds this while the rounds are avialable. I traced through to the RobotThreadManager, which ahs a cleanup() method, which is alled if you are not to replay, in this method you could remove all the static data that the bot used. Thus no major rewiring required. ;) --Chase-san

Fnl - More fundamentally, the static variables in a robot should be released when the classloader the robot was loaded in is disposed, and the suspicion here is that something (either the robot's classloader or the robot's thread) is still hanging on to something it should be able to release. It may be getting held by something within Robocode, but if it's the thread that's just stopping but not being disposed, they might hold references to objects loaded by that classloader, and that means static members in that class loader stick around. These static members already can't be accessed by future instances of the robot (in different battles), because those robots will be loaded in new classloaders (so we're not talking about breaking any existing bots). -- Kawigi

Okay. So we all agree that Robocode should clean the static variables for a robot (peer) when a battle (not round!!) is ended (or started ;-). That should be too hard to implement. I have no problem figuring out how to do this. I just wanted your oppinions upon if Robocode should be allowed to clean the static variables, as Robocode has never done this previously. Hence, if some robots keeps data from round to round, and battle to battle, then I might break the compability of keeping data from battle to battle. But hey, they should "save" the data! ;-) --Fnl

I have made a fix where all the static fields on a robot that are not final or primitive are set to null so that the garbage collector is called on these fields. I have made an alpha version that can be downloaded here. I should like you to tryout this version to see if the problem disappears? --Fnl

Yes! That worked perfectly. I'll just have to remember not to set big data structures to final. That shouldn't be hard. So ... but that still seems strange. Is the class loader being held onto, like Kawigi mentioned? -- Simonton

• Cool! I will then add it to the real 1.2.5 release (of course also the Beta). Robocode has it's own class loader for loading robots. I have full control over this. I don't use the class loader for the fix. I just clean the declared fields on the robots that are static and that are not primitives or final using trivial Java reflection, and this is done when the cleanup() method is called. --Fnl

I guess everyone has to update thier clients, that is considering that if 1.2.5 doesn't have any major bugs implimentation wise (this might actually might increase the preformance, but you know what I mean). --Chase-san

• Yes, unfortunately. I will try to minimize the risk of introducing new bugs. I had to change the robot states etc. for Robocode in order to support Replay. This introduced a few bugs, but also simplified the internal code for Robocode regarding states! ;-) --Fnl

Uhh ... everone running an alpha version for their clients doesn't sound like such a hot idea. Maybe it's best to wait at least a little while ... -- Simonton

• Hehe.. yes, I am sure that Chase-san was meaning the real 1.2.5 version. :-) --Fnl

By the way, is 1.10.3c equivalent to your best version of WeeksOnEnd? Also, does it use the Rules class? -- Voidious

• Um ... not real sure actually! I'm thinking yes and yes. It should actually be named 1.10.2c; I just got the numbering messed up. I know it has some unneeded memory management (now that the static variables are being cleaned up). Looks like my entries in The2000Club and The2100Club/Mini should be revoked. Must have been the version of Robocode I was using for my clients inflating the score back then. -- Simonton
  • Leaving you with only the measley title of MiniBot Champion, eh? =) I guess the time has come for me to use the Rules class and implement onBulletHitBullet in Komarious. I wish we could officially "require" a current client for the RoboRumble once we conclude the new versions are stable, because I really hate the Rules incompatibility and memory leak issues. Maybe after the RoboWikiRenovation we can update the RoboRumble code that way. -- Voidious
  • I would second that motion. Has there been any talk of when the renovation may actually happen? -- Simonton

Any idea how much memory WeeksOnEnd uses? I keep getting OutOfMemoryErrors when my RRAH clients run it with the default of 256MB. I've set them to 1024 for now, hopefully that will solve the problem. --David Alves

• Ooo, really? Ouch. I thought I had tweaked it to take only its fair share of 256M. Hmm ... let me run a test. Oh, ouch. 2 WeeksOnEnd in a 35 round battle brought memory usage to 378M. That's more than 256. Hmm ... I must have been planning on people running the rumble at 512M. Has the default always been 256? -- Simonton
• I thought the default had changed from 256 to 512 a while back, but I see that it is 256 in 1.4.5's roborumble.sh and 512 in robocode.sh. (I always run with 512, for whatever that's worth.) -- Voidious

• Yeah, same for the batch files. It's 512 in robocode.bat but only 256 in roborumble.bat --David Alves

---

Congrats. =) -- Voidious

• I have confidence that you can answer, should you choose. That race to 2100 still appears to be open ... -- Simonton
• Any idea what happened? WeeksOnEnd 1.10.4 has dropped to 2081 in the mini rumble. -- Voidious
• Nope, no idea. I'm just about to leave work ... though I don't even know how I might check it out once I get home. -- Simonton

I see anti-PM was mentioned above, but does the latest WeeksOnEnd in the rumble use it? Because.... by adding a PM of a similar conceptual breed as WeeksOnEnd (Single-tick, match of acceleration and turning), my rumble score against WeeksOnEnd went down from about 74 to about 49 despite some good success such as my score against Chalk going up 11 points, up 6 against Phoenix, and while there are a few drop, none as massive as the one against WeeksOnEnd. So... it is anti-PM I smell here or not? :) -- Rednaxela

Nope, there's no room in a mini =) I notice that my score fluctuates a lot against WeeksOnEnd though, from 60s to high 40s. IIRC LifelongObsession has Anti-Che movement. -- Skilgannon

Well, I would argue that it could be done in a mini, but it makes sense that this is just fluctuations. Just to check though, do you mean fluctuations between particular runs, or more fluctuations between versions of your bot? -- Rednaxela

Against different versions of several of my bots, Toorkild 0.1 beat WeeksOnEnd but 0.1.1 loses, versions of DrussGT where almost nothing has changed go from losing @ 45% to winning @ 60%, that kind of thing. -- Skilgannon

Hmm, interesting... i wonder what makes scores against WeeksOnEnd so finicky... -- Rednaxela