What is the progress on getting release mode enabled for submitted code? The debug mode has become a significant hindrance to some of the games, especially those that involve any kind of tree searching, filling, etc.
In my last stream I was hunting performance issues in my Hypersonic bot. I tried many things, and was able to come up with some awful code to speed it up. Yet it was completely useless compared to simply compiling in release mode (tested locally). All the bottlenecks were in fundamental language constructs that should have been nearly free. The debug mode had an execution time 30x longer than release mode.
Attempting to optimize in debug mode is counter-productive and results in questionable code quality. I presume CodinGame would prefer to promote clean coding skills.
Due to CG non-optimal technical architecture, adding optimization flags would greatly impact the duration of submits since we recompile your code for each battle. Granted, that sounds a bit weird, but it is how it is.
That being said, weâre willing to dive into the code and change this. Iâm sure youâll concur that this wonât be the easiest nor the safest fix of the year. Itâll take a bit of time. Considering our current priorities, Iâm confident weâll be able to tackle this during summer (vagueness intended).
Meanwhile, since there are only a few users coding in this language, we have activated release mode for Rust for submits in multiplayer games (only games with last battles).
Ah cool, thatâll be great for the show to have release mode. Thanks a lot.
Consider, with the time thing, that many languages offer intermediate optimizations modes, like -O1 for GCC, that can sometimes compile faster than the unoptimized mode and gain most of the significant speed improvements (it removes the horrible layer of debug cruft).
Quick question , is it just âonâ for all rust entries âsubmittedâ in muti-player league type games? What about when we do a test run in the âIDEâ?
Can anyone confirm they are seeing âproductionâ rust speed in multiplayer games. Based on non-debug rust being available I rewrote my MCTS Tron bot and submitted it. It is time limited in its main loop to 93ms, and, at the start of a 4 player game (longest rollouts) my figures are as follows:
Rollouts per 93ms:
Running on my desktop:(IntelŽ Core⢠i5-3550 CPU @ 3.30GHz, 4 Core(s)))
Debug : 200-250 rollouts
Non-debug: 4,500 rollouts.
Just to confirm the code is all single threaded! I was hoping for the the 4k figure on a submitted bot! and then start performance tuning it, but there is no chance of using Monte Carlo Tree Search if I have to start tuning at 230 rollouts.
So is anyone seeing rust performance on a submitted bot close to what could reasonably be expected from non-debug code?
How do you know that you have 300 rollouts in submit mode? If you send the game parameters to your ide I suspect the program is run in debug mode again.
But I donât think it is working as expected too. I am coding in the Ultimate Tic-Tac-Toe challange. When I test me code in the IDE I would suggest that I lose hard against those bots which are along my leaderboard position, because when my position in the leaderboard is calculated there would be at least 10x more computing power, since the code is compiled in release mode. But this is not the case.
Most multiplayer games let you print messages by appending them to your output (eg on CSB you print âx y thrust messageâ). You should also be able to view your debug on the replays of a submit if you click the ââŚâ button.
During, Code of Kutulu I used a FloydâWarshall algorithm with some optimisation. The implementation timeout in IDE as expected, because it toke >1s on my desktop in debug mode. But it didnât timeout (on same maze) during submission, and the printed duration are lower on submission.
So I can confirm the enabling of release mode for submission. The bad effect is that I canât replay in IDE some games from submission because they timeout
Iâm currently trying the rust language in the Ultimate Tic-Tac-Toe game but it seems that rust is in debug mode both in the IDE and in the last battles tab. I quickly tried this code and it always displays âDebugging enabledâ. Moreover, a quick test gives me approximately the same execution times in both cases.
Did you revert the release mode in multiplayer games?
I tried again today and the release mode seems completely random. Sometimes it shows âDebugging enabledâ and sometimes âDebugging disabledâ and run 10x faster. Even by running the code twice in the IDE there are different behaviors. The release mode is quite buggyâŚ
@TwoSteps Can you clarify what we should currently expect w.r.t Rust optimizations? For my own particular interest, what would be the expected behaviour in:
a) A typical contest with multiplayer environments, like Botters of Galaxy or MadMax or WondevWomen etc.
b) A contest like a*craft, where itâs competitive but the challenge environment itself isnât âmultiplayerâ
c) The contests of a/b, but after contest completion and now in âgameâ mode.
Thanks⌠and thanks for making the effort to improve the Rust experience. I realize itâs a relatively small share of total users (though positive to see that in the a*craft contest Rust implementations were at 20% of js implementations and 10% of c++!)
