Hm. Can we get a “you can use at least this amount of time per move and not be disqualified”? Without wanting to say too much, I have a strategy in mind that would rely on knowing a certain runtime is safe. (Allowing for some amount of jankiness, so that if the limit was 5s I’d consider 4s safe.)
My previous answer was a mistake. It is actually 100 move calls in 0.05 seconds. Sorry.
The numbers are brutal.
If a game goes for 50 rounds and 10 different bots each use 5[1] seconds per move and there are 550 moves per bot per pairing then it would take 4.36 years to run this tournament.
However, do note that the guarantee is “0.05 seconds per 100 moves” as opposed to “0.0005 seconds per move”. If you only have to run expensive computations once then, depending on your algorithm, the right caching system might get you close to 100× performance.
I can add caching functions to the extra package if that would help. The computer in question has 4 processors and runs Linux so multiprocessing can get you up to a 4× speedup.
Oh, geez. I figured it would be too long, but I didn’t think about just how much too long. Yeah, with these constraints, even 5s per hundred moves I agree is unreasonable.
Caching seems easy enough to implement independently, I think. No need for you to add it.
Hm. Can we get a “you can use at least this amount of time per move and not be disqualified”? Without wanting to say too much, I have a strategy in mind that would rely on knowing a certain runtime is safe. (Allowing for some amount of jankiness, so that if the limit was 5s I’d consider 4s safe.)
I will not disqualify anyone who can complete 100move
calls in 5 seconds (0.05 seconds per call on average) on my T450s.I will not disqualify anyone who can complete 100
move
calls in 0.05 seconds on my T450s.Edit: Corrected time limit downward by 100×.
Thanks. I confess I’d been hoping for more like 100x that, but not really expecting it :p
My previous answer was a mistake. It is actually 100
move
calls in 0.05 seconds. Sorry.The numbers are brutal.
If a game goes for 50 rounds and 10 different bots each use 5[1] seconds per move and there are 550 moves per bot per pairing then it would take 4.36 years to run this tournament.
5secondsmove×550movesspawning×100spawningsbot×round×50roundstournament×10bots×1tournament31,536,000secondsyear=4.36years
However, do note that the guarantee is “0.05 seconds per 100 moves” as opposed to “0.0005 seconds per move”. If you only have to run expensive computations once then, depending on your algorithm, the right caching system might get you close to 100× performance.
I can add caching functions to the
extra
package if that would help. The computer in question has 4 processors and runs Linux so multiprocessing can get you up to a 4× speedup.500 seconds per move is 100× my original limit which equals 10,000× the corrected limit.
Oh, geez. I figured it would be too long, but I didn’t think about just how much too long. Yeah, with these constraints, even 5s per hundred moves I agree is unreasonable.
Caching seems easy enough to implement independently, I think. No need for you to add it.