This question already has answers here:
Why don't compilers merge redundant std::atomic writes?
(9 answers)
Can atomic loads be merged in the C++ memory model?
(2 answers)
Closed 2 years ago.
Let std::atomic<std::int64_t> num{0}; be defined somewhere accessible/visible in the code.
Is the C++ compiler allowed to replace each of the following two codes with an empty code (something that does nothing)? Similarly, are these optimizations allowed to happen at runtime?
I am just trying to get a better understanding of how things work.
num.fetch_add(1,std::memory_order_relaxed);
num.fetch_sub(1,std::memory_order_relaxed);
and
num.fetch_add(1,std::memory_order_relaxed);
std::this_thread::yield();
num.fetch_sub(1,std::memory_order_relaxed);
I think in theory yes and even yield does not help.
But in practice no not today but possible in the future.
See:
N4455 No Sane Compiler Would Optimize Atomics
P0062R1: When should compilers optimize atomics?
"Runtime optimization" may happen if modifications coalesce. I don't know if this situation may happen in practice or not. Anyway it is not much distinguishable from "no other threads manage to observe modified value before it changes back"
In fact, the optimization effect is equivalent to "no other threads manage to observe modified value before it changes back", no matter if it is compiler optimization, or runtime. Yield is not guaranteed to help, at least because it just "gives opportunity to reschedule", which an implementation might decide to ignore. And in theory there's no synchronization between yield and an atomic operation.
On the other hand what do you expect to achieve with this?
Related
This question already has answers here:
What exactly is the "as-if" rule?
(3 answers)
Closed 3 years ago.
Situation is that I'd like to use descriptive variable names as member variables so they are well understandable in headers (for example: min_distance_to_polygon). Yet in complex algorithms I'd find it smoother to have much shorter variable names because the context is clear (for example min_dist in that case).
So in the definition of a method I'd just write:
int & min_dist = min_distance_to_polygon;
Does this cause an overhead after compilation and would this be acceptable coding style?
EDIT: Would this be better (as it prevents a possible copy)?
int & min_dist{min_distance_to_polygon};
Does this cause an overhead after compilation
Not with an optimizing compiler, no. This is bread-and-butter optimization for a compiler. In fact, even copying the value would likely not cause any overhead (assuming that it remains unchanged) due to the compiler's value tracking and/or how CPU registers actually work behind the scenes (see Register Renaming).
and would this be acceptable coding style?
That's opinion-based and debatable. I posit that there exists code where this is a reasonable choice, but that such code is rare. In the end it's up to you to judge whether future readers will find either version easier to read and comprehend.
Would this be better (as it prevents a possible copy)?
The two code snippets you show are exactly identical in their semantics - both are initialization. No operator= is invoked (even conceptually) in X x = y;.
Will a compiler remove effectless references?
It depends. It may, if it can. The language doesn't mandate optimisation, it is permitted.
Does this cause an overhead after compilation and would this be acceptable coding style?
Overhead would be highly unlikely in this case, assuming the compiler optimises the program.
In general, you can verify that a reference is optimised away by comparing the generated assembly with or without the reference. If the generated assembly is identical, then there will not be any overhead.
More generally, you can verify whether any change has significant overhead by measuring.
Would this be better
int & min_dist{min_distance_to_polygon};
It would be effectively identical.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I know it's a trick to do boolean conversion. My question is primarily about resource cost when writing this way. Will complier just ignore the "!!" and do implicit boolean conversion directly?
If you have any doubts you can check the generated assembly; noting at the assembly level there is no such thing as a boolean type anyway. So yes, it's probably all optimised out.
As a rule of thumb, code that mixes types therefore necessitating type conversions will run slower, although that is masked by another rule of thumb which is write clear code.
It depends.
If you limit attention just to basic types that are convertible to bool and can be an operand of the ! operator, then it depends on the compiler. Depending on target system, the compiler may emit a sequence of instructions that gives the required effect, but not in the way you envisage. Also, a given compiler may treat things differently, with different optimisation settings (e.g compiling for debugging versus release).
The only way to be sure is to examine the code emitted by the compiler. In practice, it is unlikely to make much difference. As others have commented, you would be better off worrying about getting your code clear and working correctly,than about the merits of premature optimisation techniques. If you have a real need (e.g. the operation is in a hotspot identified by a profiler) than you will have data to understand what the need is, and identify realistic options to do something about it. Practically, I would doubt there are many real-world cases where there would be any difference.
In C++, with user-defined types, all bets are off. There are many possibilities, such as classes that have an operator!() that returns a class type, a class that has an operator!() but not an operator bool(). The list goes on, and there are many permutations. There are cases where the compiler would be incorrect in doing such a transformation (e.g. !!x would be expected to be equivalent to x.operator!().operator!() but there is not actually a requirement (coding guidelines aside) for that sequence to give the same net effect as x.operator bool()). Practically, I wouldn't expect too many compilers to even attempt to identify an opportunity in such cases - the analysis would be non-trivial, probably not give many practical benefits (optimising single instructions is rarely where the gains are to be made in compiler optimisation). Again, it is better for the programmer to focus on getting code clear and correct, rather than worrying about how the compiler optimises single expressions like this. For example, if calling an operator bool() is intended, then it is better to provide that operator AND write an expression that uses it (e.g. bool(x)) rather than hoping the compiler will convert a hack like !!x into a call of x.operator bool().
This question already has answers here:
Enforcing statement order in C++
(7 answers)
Closed 4 years ago.
As we know, modern CPU is able to execute multi commands concurrently: https://en.wikipedia.org/wiki/Out-of-order_execution
As a result, we may get such a fact as below:
When we execute the c++ code: x = a + b; y = c + d;, y = c + d; may be executed before x = a + b;.
My question is if it is possible to disable the out-of-order execution of CPU?
No, you can't deactivate such hardware mechanism when it has it. That's what gives you performance. That's how the CPU is designed.
What C++ guarantees is that you won't be able to see the difference between what you want with the proper order, and what you will get. And that's also something that vendors like Intel will make sure for the assembly.
Have a look at https://www.youtube.com/watch?v=FJIn1YhPJJc&frags=pl%2Cwn for the C++ execution model.
All you should care about is the meaning of your program. That's not being pedantic, it is the fundamental basis around which the entire language has been designed.
A C++ program describes the meaning of a program. It is not a one-to-one mapping of source code to what a computer should literally do.
If you want that, you will have to code in assembly or perhaps some old-fashioned language from the middle ages, but even then you are going to have a hard time telling a modern CPU not to do all the clever things that it is designed to do in order to support useful programs. Certainly I'm not aware of any out-of-the-box switch, flag or setting that makes this happen; it would go against the grain of the very architecture of a CPU.
Ultimately you may be better off building and programming a Difference Engine ;)
You cannot deactivate the reordering at the hardware level (CPU level).
However, you can ensure that the compiler will not reorder by using the optimization level of debug.
This will help in debugging the program, but it will make your code slow. It is not recommended in production code.
It's not possible to disable out-of-order execution from the program, this is the well-known problem of Memory Barrier. As the problem consequences appear in multi-threading programs only, you have to use synchronization primitives to ensure the execution order.
This question already has answers here:
Does adding unnecessary curly brackets { } in a c++ program slow it down at all?
(3 answers)
Closed 6 years ago.
I know that this question has been asked and answered here, among other places, but none of the answers touched on the reason I was given (years ago) for the adverse performance impact of "unnecessary" curly braces.
In that light, I'd like to revisit this issue.
Briefly, I was told that:
if(true)
do_something();
is more performant than
if(true)
{
do_something();
}
The reason given, as I recall, was because the compiler would introduce a branch in the assembled code in the second case which could have a cumulative effect.
Now, I can spell complier, but beyond that I know very little about how they operate, so is the above theory true? Was it ever true?
In unoptimized as well as optimized generated code, those two statements would translate exactly to the same. The braces create a new scope where nothing is declared, so nothing can be implemented differently, semantically speaking. (Unless a dumb compiler would manage an empty stack frame for this inner block ?!)
so is the above theory true?
No.
Was it ever true?
No.
Not even with the worst ancient compilers lacking clever optimization strategies I could imagine these statements would emit different assenbly code.
These would simply be emitted as a call to the do_something subroutine.
The "facts" you were given are completely madeup. There is no performance reduction at all, as people have already mentioned in the very link you gave.
There is no way for us to explain the reasoning of something that's not true.
This question already has answers here:
Is there any overhead using this-> for accessing a member?
(5 answers)
Closed 7 years ago.
For quite a long time I've been using javascript where this keyword is mandatory. Now, I'm programming in c++ but habit of using this keyword remained. But the real question is - Does using this keyword have any negative impact on performance (as in unnecessary memory access)? I mean - is code omitting this more optimization friendly for compiler or it completely doesn't matter? Because well strictly theoretically, referring to this is kind of referring to pointer, like opcode $reg0, [$reg1] in assembler, which could add one more memory reference in code but i guess it should be handled by compiler in more clever way than just typical pointer, am i right?
Personally I prefer using this because I feel a bit lost in code which doesn't use it as i don't know if some variables are members or they're local or global or what, but if it'd cause performance issues I could probably force myself to avoid it.
No, an optimizing compiler (for C++11 or better) would very probably generate the same binary code for this->field and for field, and likewise for this->memberfun(2,3) and memberfun(2,3).
(probably, even without optimization, the same -inefficient- code would be produced; but I am not sure of that)
Sometimes (notably when coding templates) this is required because omitting it has different meaning (I forgot for which weird cases).
Of course, the compilation time might be slightly different. But you should not care.
Some coding conventions require, or (more often) on the contrary forbid, using this for readability reasons. Choose whatever convention you like, but be consistent.
See also this answer explaining how practically this is handled on Linux x86-64 ABI.
But the real question is - Does using this keyword have any negative impact on performance (as in unnecessary memory access)?
no.
which could add one more memory reference in code but i guess it should be handled by compiler in more clever way than just typical pointer, am i right?
yes
:-)