Re: Contest 2 Announcement:
Patrick Barnes wrote:
>
> On Sun, 28 Nov 2004 07:41:51 -0800, Andy Serpa <guest at rapideuphoria.com>
> wrote:
> > Rules suggestion:
> >
> > You must submit your orders within 2*n seconds of the "turn" beginning,
> > correct? I see a couple
> of potential problems with this:</font></i>
> >
> > A) Your machine is your machine, running at its own speed. The rest of have
> > to guess if our
> moves will take too long on your machine.</font></i>
>
> True, but I have a fairly fast machine (2.4Ghz, 512mb ram, corporate
> machine - nothing cluttering it up )
> Can you think of a better metric? My concern is that matches can take
> a long time, an entire tournament even longer.
>
The time-limit itself I'm not concerned about, but let's say I have a program
that "thinks" and I want to use my available time, whatever it is. Using a local
clock for 2 seconds * the # opponents I could implement, but not without breaking
the rules (I would need to use .dll functions) because the timer in Euphoria is
at a very low resolution (whole integer seconds) and not very suitable. Or let's
just say I have a slower machine on average my answers take 3 seconds to come up
with. I suspect that on your machine they will be fast enough, but maybe they
won't? How will I know?
>
> > B) A resource-intensive, number crunching program or something with
> > heavy-disk access will likely
> inhibit another program if they are running in parallel, even though in theory
> they should get equal slices. On Windows,
> they simply won't. There are a number of factors that can affect this, who
> started up first, is one program accessing the
> disk alot, etc.</font></i>
>
> That's true... any data file that a program uses is restricted to a
> small size though. (Perhaps I should implement file access routines in
> eubots.ew to enforce this?)
>
>
> > I would propose two changes to your evaluation routine:
> >
> > 1) Do not run the programs in parallel. Ask for and receive the orders for
> > each program in
> turn, and once you've collected all the orders, evaluate them as normal. In
> other words, simulate parallel, but don't do
> actual parallel. This will not slow things down, but it will guarantee that
> each program gets 100% resources. (It would
> also be easier to code the engine, I would think.) </font></i>
>
> Actually, it's easier like it is, because the complexity is handled by
> the windows API. 
> You're right, it would be *fairer* to do things sequentially, I'm just
> concerned about the time. Interleaving the processes makes it a lost
> quicker, because I can start *all* of the processes, and wait on *all*
> of them to finish. (See the waitForMultipleObjects function in
> kernel32.dll, it's wonderful). If it was individual, each would need
> their own timeout, and turns would take a lot longer to process.
>
I don't see why it would be faster just because you can start them all at the
same time. The real time is taken up by the bots themselves:
for i = 1 to num_bots do
-- send start msg to bot # i
-- wait up to 2 seconds for response
end for
> >There also needs to be rule addition: NO "THINKING" outside your
> allotted time. If I were to use a chess-program like algorithm, it
> could just go on calculating potential orders 100% of the time, taking
> up resources, etc. It should be enforced that the program isn't
> allowed to do anything except sit there between calls from the main
> engine for get_orders().
>
> I may be wrong, but I don't believe that's possible. No top-level
> statements are permitted, and the get_orders() function *has* to
> return. The only way the MSG_GETMOVE can be received by the bot is if
> it's waiting inside eubots.ew.
>
Ok. I have not studied how you are doing the IPC. With certain kinds of event
loops there would be nothing preventing my program from sending my moves and then
immediately start thinking about new ones while simultaneously checking for new
messages from the main program.
>
> > 2) Instead of forcing the program to return in an allotted time (which we
> > have to guess, although
> we could maintain a local clock in the program I suppose), allow each program
> to update a variable that contains a set of
> "current orders" and the system will simply take whatever the current value of
> this variable is at the end of the alloted
> time. This will allow for "anytime" algorithms that just keep updating an
> answer the longer they have to think about it.
> If the program has a "definite" answer, it can submit as soon as its ready,
> of course.</font></i>
>
> That is an interesting idea... The way that it works currently is that
> if the program is late in returning orders for turn N, its orders are
> used in turn N+1, by which time they may not be useful.
>
Again, depends on your IPC. If you were to use pipes to each program, it could
send an updated answer continously until the time runs out. That's how chess
engines work.
> > These changes would likely slow down the evaluation because people might
> > want to use all of
> their time each turn, but it would allow for more complex and interesting
> strategies. It would also allow the program to
> do evaluation itself iteratively by examining possibilities instead of trying
> to hand-code every nuance of the strategy.
> This would also potentially mean that certain bots would get stronger the
> faster the machine the tournament is run on. You
> may or may not like this implication. You could also ban these sort of
> endless loop algorithms altogether, I suppose, but
> one way or another I think you need to deal with the
> possibilities...</font></i>
>
> Well, at some stage it has to relinquish control, or it won't be able
> to wait on the signal for new orders. I will absolutely not allow a
> timeout or non-blocking call to wait for a new orders signal.
>
> Otherwise...
> procedure run_match(sequence initial_orders, sequence initial_metrics)
> while 1 do
> start_time = time()
> *figure out orders*
> temp = sendOrdersAndWaitForUpdate(orders)
> arena = temp[1]
> metrics = temp[2]
> end while
> end procedure
>
> Like this? I don't see how it's any different from the current
> functional implementation. The only difference being that the local
> variables stay... and that is academic, because you can have global
> variables if you want...
>
> What do others think? Would you prefer a setup like this?
> (I'm not going to allow both functionl and this, I think that'd be a
> large headache.)
>
I'm not I understand the alternatives because I haven't studied your code. Just
some things to think about -- I'm sure we can work within whatever the rules are.
I'm asking about all this because I'll probably make a infinite loop type
program myself and I want to:
A) Make sure I get my moves in on time and recognized.
B) Don't mess up other people's programs because I am hogging the CPU, etc.
|
Not Categorized, Please Help
|
|
