It’s not that it would generate buggy code, but that it could generate suboptimal bloated code with O3 compared to O2.
Yes compiler optimizations can generate bugs (as @MaximeC pointed out in his initial response).
The more aggressive/advanced are the optimizations performed by the compiler, the higher is the risk of introducing bugs.
But those bugs happen in exceptional cases and should not be problematic if we are able to turn compiler optimizations off (or use a lower optimization level like -O2 instead of -O3).
This SO answer is arguably incorrect. The compiler is free to take any action possible when compiling a code that shows undefined behavior. This is not a bug in the compiler, it is a bug in the program.
Just to be clear, when I say that -O3 can generate bugs you don’t have with O0, I don’t wanted to say that it’s the compiler’s fault. You can write some bad code that works by chance without optimization but breaks when the compiler tries to legitimately optimize the code. My point was that you should be able to test in the IDE with the same compilation options as those used when you submit your solution.
Thanks for the stackoverflow link, that’s an interesting discussion.
I’m still in the camp though that it’s the programmer’s fault if a legitimate optimization breaks your code. Being able to choose between no optimization and full optimization should give you enough tools to find the mistake you made, there is no need on CodinGame for -O2, -O1 or even more fine-grained option control.
looks like it still prints debug info with -O3 -g, and optimizes code like without -g
would u add -O3 everywhere for a day to test it?
So its 2018, are we adding the O3 compiler option ?
I didn’t even know the
#pragma GCC optimize "O3,omit-frame-pointer,inline" was a thing until @MadKnight told me about it.
As someone who heavily uses STL (vectors, map, set, etc), I realized that I was actually doing the worst thing possible. I honestly think not having the O3 flag is just bad for all C++ programmers.
I think adding it as a separate language is too much. Maybe a simple checkbox that says
Enable Compiler Optimization would be a really good idea.
Maybe a simple and acceptable solution for CG would be to add just another language: assembly. Some resourceful coders have already taken this road, but it would be more official this way. In addition, the deal would be clear: you submit low-level code, you get low level error reporting in return.
The advantage of this solution, is that it would preserve the current statu quo regarding language inequality (if any) and optimization options. In addition, the existing code base in C++ would be left unaffected. Last but not least, the new language would offer a solution for any coder keen enough to compile its code written in its favorite language client side before submitting it.
I’m still pretty new to coding. How much faster is C/C++ with the optimizations and non-optimizations compared to Python? Like if we were to calculate distances between a million different points using numpy in Python, would C be 10% faster? 100% faster? 1000% faster? I’m looking for a general idea of how much I’m putting myself in a disadvantage in these contests by using Python.
Old topic. I don’t know how much “slower” is Python compared to C++, especially on a contrived example such as calculating the distance between a million points. But, if you know Python better than C++ or simply just prefer it and that it allows you to devise solutions and experiment new approaches faster, you are not putting yourself at a disadvantage by using it. From this point of view, CG platform is perhaps inducing bad habits by forcing some player to feel constrained too soon by the hardware.
As much as I’d love there to be assembly in CG (and, in all seriousness, multiple assemblies), the current code size limitation is going to be a major headache.
Then again, I’m not sure how it could be properly implemented with their current arbitrary policy of no code obfuscation.
I don’t see the harm in writing an assembly and then reverse-compiling it into a version of c that will get that assembally back. Not in MP anyway. There are constraints around readability in contests but. It’s assembly so if you have clever your naming rules for decompilation you surely wouldn’t be hurting it?
I definately suggest adding an option to toggle the flag somehow.
I am new to C++ (48h of coding) but I already noticed big changes between my local optimised code and the one compiled on CG.
As a matter of fact, the line numbers for a crash rely on the -g flag, and not the -O flag.
I debug my local code compiled with O3 and g and it is still able to provide filenames and line numbers of any crash.
Also, the O3 creating bugs is more of a legend imho, haven’t ever had any problem (maybe you get some in embed system or kernel corner cases but I highly doubt someone will ever see them in a userspace app on CodinGame).
Besides, if that’s really an issue, O2 would still be acceptable and doesn’t have the reputation of having that problem.
(Note that here again, I’m not talking about bugs that exist and only show under O3. Those are the cause of bad coding and not flags, and should be fixed by the contestant.)
I find not having optimization flags so absurd that I didn’t even think that was possible.
So far, I’ve been writing my code carefully flagging every const function as “const”, without “inline” flags and letting the compiler do the optimization : its job.
It’s a shame it didn’t, for several reasons :
- When people code in C++ they expect it to do so. I would have coded differently (understand, in a tremendously ugly way for it to be faster) if I knew it didn’t. And I wouldn’t have enjoyed it.
- It would reduce server load, games would compute faster.
- It would allow for more clever IAs, more pleasant fights to watch in versus games.
- The fact C++ is faster than say Python for real world applications is also something REAL that it’s good to teach to people.
Sometime with the -O flag the stack is not complete, even with -g flag. Some line can be missing (because of the inlining) and most of time you can see in the stack instead of your functions/variables.
But [CG]Thibaud said in a topic that this issues will be addressed during summer. So wait and see i suppose.
I believe it’s a bot. I hope so …
Is there any progress?
Swift has same issue too,
local build is 10 times faster then build on CG.
And looks like you have no tricks like c++ #pragma
Any solution in 2022?