The difference between debug and release is really huge. Please compile in release!
4 Likes
Using rust in debug mode is like writing code with the complexity of C++ and the performance of Python. Please fix this 
6 Likes
Any update about enable the flag “-O” ?
Is it planned or not ?
3 Likes
I asked a member of CG staff directly recently, and it turns out that they are currently trying to overhaul the compile/execution system. So whilst they aren’t currently planning to do this directly, there is hope for more flexible compilation in future.
Also, I’ve started a project to bundle up my own rust project codebases for cg puzzles/games into a single file for CG, and plan to find ways to perform optimisations in the bundler that improve the code’s performance on CG (a friend has some ideas for it, as well). I shared it with this topic.
3 Likes
Has there been any progress with allowing optimization for Rust code?
Rust in debug mode is really slow and will ignore inline directives. Even the lowest optimization level would fix that without blowing up compile times too much, though of course higher would be better.
Compiling all code with optimizations is not desirable, though, since debug mode has a lot of useful checks like integer overflow checks. A kind of a flag to tell whether you want it in debug mode or not is needed, which could just be a special comment, as long as it’s documented properly. (maybe in the template?)
Maybe something like:
// CodinGame: extra-compiler-flags: -C opt-level=3
This could then be extended for other languages and runtime parameters, if needed.
I prefer using a comment here because you actually can package it with the code, unlike a checkbox or such. A (minor?) challenge here is documentation.
If it’s not preferred to give coders that much power, you could limit the options to something like:
// CodinGame: compile-release-mode: true
5 Likes
Really want to see this. Would like to use this site to practise Rust and it’s fine for the practise exercises but for anything competitive it will fall short without optimisations. “Zero-cost”/compile-time abstractions are idiomatic in Rust, to the point that the for-loop only works via iterators, which should be compiled away in simple scenarios.
2 Likes
In debug mode, not even the range iterators get optimized away, you end up with explicit monomorphised calls to IntoIterator::into_iter and Iterator::next. As you can see here: https://godbolt.org/g/29MrHv
Specifically:
example::sum_from_to:
push rbp
mov rbp, rsp
sub rsp, 80
mov dword ptr [rbp - 60], 0
mov dword ptr [rbp - 56], edi
mov dword ptr [rbp - 52], esi
mov esi, dword ptr [rbp - 56]
mov edi, dword ptr [rbp - 52]
mov dword ptr [rbp - 32], esi
mov dword ptr [rbp - 28], edi
mov rdi, qword ptr [rbp - 32]
call <I as core::iter::traits::IntoIterator>::into_iter
mov qword ptr [rbp - 16], rax
mov rax, qword ptr [rbp - 16]
mov qword ptr [rbp - 24], rax
mov esi, dword ptr [rbp - 24]
mov ecx, dword ptr [rbp - 20]
mov dword ptr [rbp - 64], esi
mov dword ptr [rbp - 68], ecx
mov eax, dword ptr [rbp - 64]
mov dword ptr [rbp - 48], eax
mov ecx, dword ptr [rbp - 68]
mov dword ptr [rbp - 44], ecx
.LBB9_2:
lea rdi, [rbp - 48]
call core::iter::range::<impl core::iter::iterator::Iterator for core::ops::Range<A>>::next
mov qword ptr [rbp - 8], rax
mov rax, qword ptr [rbp - 8]
mov qword ptr [rbp - 40], rax
mov eax, dword ptr [rbp - 40]
test eax, eax
jne .LBB9_5
jmp .LBB9_4
.LBB9_4:
mov eax, dword ptr [rbp - 60]
add rsp, 80
pop rbp
ret
.LBB9_5:
mov eax, dword ptr [rbp - 36]
add eax, dword ptr [rbp - 60]
setb cl
test cl, 1
mov dword ptr [rbp - 72], eax
jne .LBB9_7
mov eax, dword ptr [rbp - 72]
mov dword ptr [rbp - 60], eax
jmp .LBB9_2
.LBB9_7:
lea rax, [rip + panic_loc.4]
mov rdi, rax
call core::panicking::panic@PLT
3 Likes
I coded Minimax for Wondev Woman in rust but I cannot run a depth of more than 2. Resulting in a very bad AI 
Any updates concerning the compilation with optimization ?
By the way which version of rust is used ?
4 Likes
Any update?
5 Likes
Hi,
Is there any news on this subject ?
I would like to use Rust for the next contest but if the performances are not up to it I should stop learning Rust right now!
Thanks.
1 Like
Sorry for the lack of information. Unfortunately, we won’t be tackling optimization flags before next year. First, we are updating all the languages versions.
Ok thanks for the info, let’s look at some C++ then 
Any news ?
3 Likes
Please fix this, I had to junk my entire strategy (and several days of work) for botters due to the huge overhead of debug mode. It’s just one flag to add to the compilation command after all.
2 Likes
Hey tha’ts exactly what we said about O3 and C++. This was 2 years ago. We still don’t have O3. Have fun.
Troll aside, i’m not sure why codingame refuse to touch at compilation/run command line even when all the community is asking for it. This issue is not specific to Rust, many langages share the same (bad compilation/run command line).
Most of the time, Codingame argument is “if we change the command line, many current working codes will not work anymore and we don’t want it”.
1 Like
For clarification though, some things in Rust are SLOW in debug mode. Like python and ruby run rings around it, its very stupid. There are clash of code challenges etc, even very very simple challenges, where debug mode Rust just actually can’t deliver the answer in the allotted time, especially without rewriting all the IO code provided as a start. Honestly its pretty stupid just how slow Rust debug mode is relative to its release performance but yea, normally who cares, just compile in release mode…
The IO stuff for example on botters with the default code was taking me over 40ms, up to like 42, leaving 8ms to actually solve the problem else timeout.
4 Likes
well, that argument is obviously completely bogus, just saying.
1 Like
Yesterday I discovered that pretty much all of my C++ submissions in fact did stop working, just as a result of normal language updates! Some of my Rust submissions have died too.
So, I repeat. The arguement that it will break existing submissions is completely bogus. 
Realistically, if anything, it’s in CG’s benefit to enable optimisation flags, it could reduce their server loads substantially!
1 Like
Do you have any real example of these code that currently work in rust’s debug mode that would not in release mode ?
Aside from panic the behaviour is meant to be the very same. The only actual difference being the execution speed.
Some extra check are disabled in release mode that would panic in debug mode (such as overflow/wrapping).
So the actual argument would be :
EDIT:
I remembered a discussion about that last year :
That thing about debug purposes makes sense though.
Please add some option where you can choose to run your program in release or debug mode. Then set the default to debug. Everybody would be happy.