@mathias, I agree that speeding up simulation in general is a good thing no matter what technique you use.
In my experience most bots are fast, even my python bots are reasonably fast, but you can definitely optimize the game engine processing time .
Here (similar to last year) are the things that helped me.
a) recompile the halite env to your own architecture (eg using gcc -o3 -march etc) . This gave me around a 2x speedboost per core, per game, so i would recommend you do this regardless of anything else, ie compile with optimal flags. It can't hurt.
b) if you are testing a bot, terminate the game as soon as that bot dies. This is useful when testing four player games, as if your bot dies early you neednt wait till the other three finish .
@harikmenon1 or halite mods, is there an easy way to early terminate a game as soon as a particular player dies ?
i am currently doing it rather clumsily by altering the env source code, passing a new flag in and altering the game_complete function . Players like @mathias will i think benefit from an early-termination trick. Note this is not the same as using a low max_turns param in the config file.
c) The biggest speedup i got was from rewriting the engine so that bots communicate via function calls rather than stdio. You neednt rewrite it in an obscure language (i happened to choose matlab because it's pretty good at making parallel and multi-gpu code easy). But you could for example rewrite the engine with minimal hassle in c++ , reusing a majority of code
After all this, i can run approx 5 games a second , with extensive auxiliary computations i use for my RL bot- or around 30 games per second if i am simply running the games full-tilt. I do have lots of cores.
d) I disagree with @scottlegrand that it's fundamentally a compute-bound problem (hear me out, this is actually a good thing... ) Like Halite 1, i expect this one to also be won by artisanal human players who use ingenuity. Merely throwing tons of brute-force at it will never be enough. In the next few days if i get time i hope to put a "concrete info on RL" post like the one i did last year, (this one down memory lane) :
detailing how a bit of clever parametrization can massively reduce the search space. I am not using MCTS or SARSA type techniques- more like policy gradient, a bit of implicit actor-critic, and improvement-operator . @mathias, if this is greek dont worry- read my last years post and it's basically the same sort of idea, or wait a few days and with luck i'll have a post up by the end of the week.
The end of the year tends to be massively busy - i am looking forward to hols and one last good push on Halite 2 !
good luck everyone.