[Melbourne-pm] Timer::HiRes and alarms? (Was: AI Contest)

[Nathan Bailey]

I'm using the MyBot.pl from your git repository, which has:
  local $| = 1;
at the top, so I presume that would make it autoflush, so the alarm  
could print.

I gave up on trying to work out the SIG ALRM stuff. I don't think I've  
ever had a genuine timeout. The only times I see timeouts are:
	1. Bad code (the engine doesn't like "stderr", despite the docs, so  
if I forget to tag a 'warn', it often fails; otherwise general crashes  
and bugs)
	2. When I've had while loop where the exit condition wasn't reached  
(programmer error :-)
I was going to use Benchmark::Timer to profile my code, but Kim's  
suggestion of NYTProf is a much better one.

I have written a simple engine that lets me trap most of my errors  
(although it doesn't reproduce the results of the java engine so  
presumably it has bugs too :-)
I'm happy to share (eg. publish it in your git repository) it if no- 
one laughs at my code ;-) [ especially if people can fix its bugs! ]

When I started, I wasn't sure if I just submitted 'MyBot.pl' or all  
the .pms too, so I avoided putting code into modules and undid my  
initial changes to PlanetWars.pm
I think PlanetWars.pm could be way more efficient and could have a  
number of other helper functions (eg. ClosestPlanet() would be an  
obvious one)

Unfortunately I seem to be able to generate bugs that can't be  
reproduced with either the local java engine or my simple Perl engine,  
and are sometimes hard to even debug on the tcp server. At the moment,  
I issue some orders and finish the turn and end up in an endless loop  
of undefined input (ie. '  next unless defined($current_line); ')  
which is pretty hard to debug, beyond simply truncating my code to  
find a codebase that it doesn't happen to. Even if I send 'go' I still  
don't get any input back, and I never get the final 'you timed out,  
you lose' messages either.

re,
N

On 11/11/2010, at 3:42 PM, Toby Corkindale wrote:

> On 05/11/10 14:20, Nathan Bailey wrote:
>> So the contest requires each turn to be submitted within one  
>> second. So
>> logically, one would endeavour to use Time::HiRes and an alarm to  
>> make
>> sure that you submit a turn no matter what happens, but I seem to  
>> have
>> the syntax for Timer::HiRes/alarm's wrong. I would expect that this:
>>    eval {
>>       local $SIG{ALRM} = sub { warn "Alarm initiated\n"; print "go 
>> \n"; };
>>       setitimer(ITIMER_REAL, 0.9);
>>       while(1) { ; }
>>    };
>>    if ($@) {
>>       warn "Alarm happened?";
>>       die $@;
>>    }
>> would:
>>  a) initiate an alarm event 900ms after the setitimer statement is  
>> run
>>  b) submit an end turn command ('go') to stdout/the server =  
>> successful
>> turn completion
>>  b) make the $@ block run when it does time out (as it will, with our
>> while(1))
>>
>> So the above code should successfully submit empty turns every turn.
>>
>> 'Alarm initiated' does get printed, but 'go' doesn't seem to go to  
>> the
>> server. Am I using alarm wrong or is this a contest-specific issue?
>
>
> Hi Nathan,
> Did you ever establish what was going on here?
>
> Also, I was just wondering - have you actually been having trouble  
> doing enough processing inside 1000 ms?
>
> There was a point when I was exceeding it, but I was doing a lot of  
> work over and over; It was helpful to create some data structures to  
> hold everything at the start of each that I could just reference  
> later.
> Also, note that some data won't change at all over the course of the  
> game - the location, growth rates, and distances between planets.
>
> I note that the default starter packages are not terribly optimised  
> either. For instance, whenever you request a planet by ID, it finds  
> it by iterating over the whole lot of planets, and checking to see  
> if the ID matches. >.<
> A quick optimisation would be to use List::Util's "first", and a  
> better optimisation would be to store the planets in a damn hash  
> table.
> (List::Util is in core Perl 5.8.8 isn't it?)
>
> I recommend sticking the fleets into a hash table based on  
> destination while you're at it..
>
> Cheers,
> Toby
> _______________________________________________
> Melbourne-pm mailing list
> Melbourne-pm at pm.org
> http://mail.pm.org/mailman/listinfo/melbourne-pm