Yeah you're right. In any case I suppose everything is running in a VM so we can't break anything
Yes, if functions are inlined, you might only get the line number of their call site, but you will get line numbers anyway.
Which, I presume, is why CG avoids optimization in C++. For new users just learning a language, this may be very confusing, especially if the new user doesn't know the ins and outs of optimization, or even that such a thing exists! Not saying you're wrong. Just pointing out that CG's stance is a valid one.
Excellent! Thanks @rOut for figuring this out!
I've tried my (STL heavy) solution for the Skynet Revolution - Episode 2 puzzle with this pragma:
#pragma GCC optimize "O3,omit-frame-pointer,inline"
This gives me a factor 4-5 performance increase.
I never said it is simple It is just an idea of how to implement this
Thank you Maxime for your response.
I suggest to have the choice between at least the following options :
1) No optimization (for debugging purpose)
2) -O2 optimization flag (in case -O3 generates bugs)
3) -O3 optimization flag (for FULL speed C++ !)
The best would be to be able to give explicitly our own compilation flags in the IDE.
2) -O2 optimization flag (in case -O3 generates bugs)
Do you have any evidence that an optimization in GCC 4.9.2. introduced a bug? And I don't mean any invalid or buggy code that got it's bug exposed under optimization (such as some dangerous const_cast cases which work in a debug build, but fail in a release build, for example).
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?
C++ Code Bundler
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.