This question already has answers here:
Difference between "while" loop and "do while" loop
(16 answers)
Closed 7 years ago.
can anybody tell me the basic difference (in terms of efficiency) between the while loop and do while loop in c++ ?
I tried to search it through web but couldn't find the exact answer.
There is no difference in terms of efficiency. Both amount to a condition evaluation and a conditional jump.
If the optimizer does not insert redundant code, a top checked loop is slower because of the extra jump required. If the optimizer does insert redundant code, the top checked loop will be trivially slower because of the redundant code itself and because of its cache impact.
If the correct behavior is that the body is executed at least once, then a top checked loop is less efficient (by more than the cost of one extra execution of the condition). But that still is usually not a reason to choose bottom checking on the basis of efficiency. Choose the one that makes the code more understandable to a human maintainer.
Programmers are used to looking at while loops (top checked loops) in which the condition is trivially true (from a human point of view) on the first pass. The loop is still more readable top checked. If the first pass is so trivially true that even the compiler sees it (occurs less often than you might guess) then there is really no efficiency difference.
Often the condition you want to test cannot even be computed until once through the loop. Then I find a bottom checked loop more readable. The common practice of making dummy inputs to the condition in order to top check something trivially true, is just distracting.
The do while loop ensures that the body of the loop executes at least once.
it depends on how much you need to use it, i saw this good example of when you need to use the do while loop
Perhaps you've written a graphical program that runs an animation. When the game ends, you need to show your players the scoreboard. Of course, you need to run the animation loop at least once just to render the scoreboard. So: run your animation in the loop and do the conditional at the end to see if you should stop animating because the game is over.
Related
I'm asking regarding answers on this question, In my answer I first just got the time before and after the loops and printed out their difference, But as an update for #cigiens answer, it seems that I've done benchmarking inaccurately by not warming up the code.
What is warming up of the code? I think what happened here is that the string was moved to the cache first and that made the benchmarking results for the following loops close to each other. In my old answer, the first benchmarking result was slower than others, since it took more time to move the string to the cache I think, Am I correct? If not, what is warming up actually doing to code and also generally speaking if possible, What should I've done else than warming up for more accurate results? or how to do benchmarking correctly for C++ code (also C if possibly the same)?
To give you an example of warm up, i've recently benchmarked some nvidia cuda kernel calls:
The execution speed seems to increase over time, probably for several reasons like the fact that the GPU frequency is variable (to save power and cooldown).
Sometimes the slower call has an even worse impact on the next call so the benchmark can be misleading.
If you need to feel safe about these points, I advice you to:
reserve all the dynamic memory (like vectors) first
make a for loop to do the same work several times before a measurement
this implies to initialize the input datas (especially random) only once before the loop and to copy them each time inside the loop to ensure that you do the same work
if you deal with complex objects with cache, i advice you to pack them in a struct and to make an array of this struct (with the same construction or cloning technique), in order to ensure that the same work is done on the same starting data in the loop
you can avoid doing the for loop and copying the datas IF you alternate two calls very often and suppose that the impact of the behavior differences will cancel each other, for example in a simulation of continuous datas like positions
concerning the measurement tools, i've always faced problems with high_resolution_clock on different machines, like the non consistency of the durations. On the contrary, the windows QueryPerformanceCounter is very good.
I hope that helps !
EDIT
I forgot to add that effectively as said in the comments, the compiler optimization behavior can be annoying to deal with. The simplest way i've found is to increment a variable depending on some non trivial operations from both the warm up and the measured datas, in order to force the sequential computation as much as possible.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
When I was a freshman, our instructor allowed us to use break or continue in loops. I did it most of the time back then since it terminates/continues the loop. And now I'm in sophomore years, my instructor told me that the use of break/continue is not advisable. Can you tell me why? What affects break/continue by the way?
Some people think that it's bad to have a too complex control flow, which means things like break, continue and multiple returns. The reason is not technical, but mostly that complex control flow can make it harder to verify, test and and reason about a program.
It is however largely a matter of style, personal taste, and your overall structure. With small, well-purposed functions, there might be little to no harm in having multiple possible flows. In C++ in particular, early exit is a popular idiom and can often make code easier to follow.
At least in C, you should not be using break and/or continue "most of the time" (as your question says you used to do) to control the flow of your loops. Your loop condition should indicate under what circumstances the loop should stop; somebody maintaining your code should not have to dig through the code in the body of your loop to see what triggers the break that causes the loop to stop.
For example, let's say you want to read a number of integers from a file inputFile to see if one of the integers is 500. One way of structuring the loop is:
while (fgets (buffer, sizeof (buffer), inputFile)){
sscanf (buffer, "%d", &num);
if (num == 500)
break;
}
Here, the person reading your code has to read your entire while loop to figure out what you are actually looking for in the file. If you write this without the break:
while ((num != 500) && fgets (buffer, sizeof (buffer), inputFile))
sscanf (buffer, "%d", &num);
the loop condition itself tells the reader exactly what your code is trying to do, which makes it a lot more easy to understand quickly. Also, as a bonus, you have saved a few lines of code.
Now imagine a more complicated while or for loop, where the break is buried deep inside the body of the loop. It's easy to see why trying to find the break trigger would get annoying. Having a properly structured loop condition is much more, um, self-documenting.
There are, of course, cases where break and continue are in fact good ways to write the code. For example, if the condition at which the loop should end might occur in the middle of the loop execution, and there's a long set of statements that follow inside the loop, and executing those statements would add processing time without accomplishing anything useful, sure, go ahead and use the break. But those cases are the exception, not the "most of the time".
Most of the logic I've seen for reasoning about code correctness
supposes single entry/single exit. If your loops are filled
with break and continue, it becomes impossible to know
whether your loop invariants are met, or whether you always make
progress (so the loop won't be endless). (Note that the do
{ ... } while (...); loop also suffers from this; the loop
invariants aren't established the first time through, which can
lead to some surprises.)
Most of the cases where you are tempted to use break or
continue, you've probably made the loop (and the function
which contains it) too large and too complex.
Some would argue that something like:
for (;;) {
// ...
if ( conditionMet ) {
break;
}
// ...
}
would be acceptable for the classical loop and a half idiom; it
is single entry/single exit, after all, even if the exit isn't
quite where we expect it (and is very hard to find when reading
the code). The problem concerning loop invariants remains; the
aren't met before the if, at least the first time through.
Generally, a better solution would be to put the code before the
test into a separate function, which returns conditionMet, and
use:
while ( doLoopPrefix() ) {
doLoopSuffix();
}
(In general, if your loop is more than three or four lines, you
should refactor. Except maybe if it contains a single switch
statement, with a lot of cases.)
What is code branching? I've seen it mentioned in various places, especially with bit twiddling, but never really thought about it?
How does it slow a program down and what should I be thinking about while coding?
I see mention of if statements. I really don't understand how such code can slow down the code. If condition is true do following instructions, otherwise jump to another set of instructions? I see the other thread mentioning "branch prediction", maybe this is where I'm really lost. What is there to predict? The condition is right there and it can only be true or false.
I don't believe this to be a duplicate of this related question. The linked thread is talking about "Branch prediction" in reference to an unsorted array. I'm asking what is branching and why prediction is required.
The most simple example of a branch is an if statement:
if (condition)
doSomething();
Now if condition is true then doSomething() is executed. If not then the execution branches, by jumping to the statement that follows the end of the if.
In very simple machine pseudo code this might be compiled to something along these lines:
TEST condition
JZ label1 ; jump over the CALL if condition is 0
CALL doSomething
##label1
The branch point is the JZ instruction. The subsequent execution point depends on the outcome of the test of condition.
Branching affects performance because modern processors predict the outcome of branches and perform speculative execution, ahead of time. If the prediction turns out to be wrong then the speculative execution has to be unwound.
If you can arrange the code so that prediction success rates are higher, then performance is increased. That's because the speculatively executed code is now less of an overhead since it has already been executed before it was even needed. That this is possible is down to the fact that modern processors are highly parallel. Spare execution units can be put to use performing this speculative execution.
Now, there's one sort of code that never has branch prediction misses. And that is code with no branches. For branch free code, the results of speculative execution are always useful. So, all other things being equal, code without branches executes faster than code with branches.
Essentially imagine an assembly line in a factory. Imagine that, as each item passes through the assembly line, it will go to employee 1, then employee 2, on up to employee 5. After employee 5 is done with it, the item is finished and is ready to be packaged. Thus all five employees can be working on different items at the same time and not having to just wait around on each other. Unlike most assembly lines though, every single time employee 1 starts working on a new item, it's potentially a new type of item - not just the same type over and over.
Well, for whatever weird and imaginative reason, imagine the manager is standing at the very end of the assembly line. And he has a list saying, "Make this item first. Then make that type of item. Then that type of item." And so on. As he sees employee 5 finish each item and move on to the next, the manager then tells employee 1 which type of item to start working on, looking at where they are in the list at that time.
Now let's say there's a point in that list - that "sequence of computer instructions" - where it says, "Now start making a coffee cup. If it's nighttime when you finish making the cup, then start making a frozen dinner. If it's daytime, then start making a bag of coffee grounds." This is your if statement. Since the manager, in this kind of fake example, doesn't really know what time of day it's going to be until he actually sees the cup after it's finished, he could just wait until that time to call out the next item to make - either a frozen dinner or some coffee grounds.
The problem there is that if waits until the very last second like that - which he has to wait until to be absolutely sure what time of day it'll be when the cup is finished, and thus what the next item's going to be - then workers 1-4 are not going to be working on anything at all until worker 5 is finished. That completely defeats the purpose of an assembly line! So the manager takes a guess. The factory is open 7 hours in the day and only 1 hour at night. So it is much more likely that the cup will be finished in the daytime, thus warranting the coffee grounds.
So as soon as employee 2 starts working on the coffee cup, the manager calls out the coffee grounds to the employee 1. Then the assembly line just keeps moving along like it had been, until employee 5 is finished with the cup. At that time the manager finally sees what time of day it is. If it's daytime, that's great! If it's nighttime, everything started on after that coffee cup must be thrown away, and the frozen dinner must be started on. ...So essentially branch prediction is where the manager temporarily ventures a guess like that, and the line moves along faster when he's right.
Pseudo-Edit:
It is largely hardware-related. The main search phrase would probably be "computer pipeline cpu". But the list of instructions is already made up - it's just that that list of instructions has branches within it; it's not always 1, 2, 3, etc. But as stage 5 of the pipeline is finishing up instruction 10, stage 1 can already be working on instruction 14. Usually computer instructions can be broken up like that and worked on in segments. If stages 1-n are all working on something at the same time, and nothing gets trashed later, that's just faster than finishing one before starting another.
Any jump in your code is a branch. This happens in if statements function calls and loops.
Modern CPUs have long pipelines. This means the CPUs is processes various parts of multiple instructions at the same time. The problem with branches is that the pipeline might not have started processing the correct instructions. This means that the speculative instructions need to be thrown out and the processor will need to start processing the instructions from scratch.
When a branch is encountered, the CPU tries to predict which branch is going to be used. This is called branch prediction.
Most of the optimizations for branch prediction will be done by your compiler so you do not really need to worry about branching.
This probably falls into the category of only worry about branch optimizations if you have profiled the code and can see that this is a problem.
A branch is a deviation from normal control flow. Processors will execute instructions sequentially, but in a branch, the program counter is moved to another place in memory (for example, a branch depending on a condition, or a procedure call).
Is it possible to add N count of bytes at the end of the function?
My simple idea is to add the following code:
_asm {
NOP
NOP
NOP
NOP
NOP
}
Are there any other ways to do it? (with code, compiler or other methods)
I need it for the hotpatching the function. I have a function that has some IF statements, the function is called 10 times a second or more often. So, in order to increase performance I need to make less checks like "do I need to execute that code?".
The boolean in IF statement is not changed so often (i'd say very rarely). I also want to achieve that if I don't need to execute some code, I don't need to check for that.
You could write the function with a one point return and add in NOPs before the return statement. Although this is platform dependent.
Another method is to place garbage code before the return statement and jump around the garbage code using a label and a goto.
Be aware of compiler and linker optimizations that may remove unused code.
MSVC has the compiler option /hotpatch whick allows the linker option /functionpadmin which modifies the processing of the final binary in such a way that hotpatching should work for valid functions. You can specify the number of reserved bytes to allow for hotpatching. See the link for details.
In general, yes, although you'll need to write your function in assembly to do so.
On the other hand, it looks like what you're doing is micro-optimising your code rather than benchmarking it. BOOLs and conditionals in C++ are really, really fast, and the cost of patching opcodes on modern systems can cause really really surprisingly bad performance penalties (for example, the call to VirtualProtect to make the code writable is going to cost hundreds of thousands more than a single conditional, and you'll force pipeline stalls and cache misses by changing the function inline even if you're running on an embedded system).
So in summary, yes, what you're doing is possible. But unless you are doing this as an "out of interest" excercise or run in a very strange environment where performance of conditionals is critically important but you still write in C, then you probably want to just benchmark your code instead and find the real places where it's slow, instead of going to huge amount of pain and effort to patch things that aren't actually performance critical.
the function is called 10 times a second or more often. So, in order to increase performance
Is your function taking 50-100 milliseconds of time to complete? I mean, is there really a perf problem here? 10 times a second is nothing for simple and regular functions, but can be a lot for some computationally intensive stuff.
There's no universal way of forcing a compiler to do that, to reserve some space. You might be able to find a special way for a specific compiler, but a better approach would be to have multiple versions of the same code or constructing the code on the fly at run time.
Is it better to calculate x-1 into a variable and then use that?
I have a for loop and inside (x-1). Is it better to create
new variable y=x-1, and then use y inside the loop, rather
then recalculate it many times in the for loop? I will save
many subtractions. Not sure if this is some optimization?
Don't under or over estimate the capabilities of the compiler.
Profile first.
Look at the assembly language listing of the optimized version for the function.
The compiler may be able to combine the X-1 with another instruction.
Wait until the code works completely and is robust before making optimizations. Often times, code is harder to debug when it is optimized and you could be wasting your time optimizing code that isn't used frequently.
If x does not change inside the loop, then the compiler will most likely optimize it and calculate it only once, so it should not matter. (Of course, if x does change inside the loop, then it goes without saying that you should recompute it inside the loop).
Aside from the optimization aspect, it is probably more important to write the code so it makes the most sense to another programmer (e.g., someone maintaining the code). If using x-1 inside the loop makes the code clearer, it is almost certainly better to write it that way. Unless the loop is extremely critical to overall performance, it is (in my opinion) better to focus on making the code easier to read.
Yes, that will help speed up your code. Anything that decreases the number of calculations you need to perform will increase the speed of your code, especially if your loop goes through a lot of iterations.
No need to do something over and over again if you can do it just once :)
This is assuming that x doesn't change during your loop, though. If x does change, then you'll need to recalculate it because y will be different each time through the loop.