Sign in to follow this  
TEUTON

writing infinite loop

Recommended Posts

TEUTON    100
This was asked from my friend in an interview. Which is a efficient way of writing an infinite loop?? I guess all are same, what do you think guys?

Share this post


Link to post
Share on other sites
Drew_Benton    1861
I'm not sure what an "efficient" way would be to writing an infinite loop, since it is an infinite loop, but I'd guess: while(1){ } or for(;;){ } So yea, the question needs more context to make sense. (The question they asked, not you)

Share this post


Link to post
Share on other sites
simon10k    220
Is while(true); more efficient than while(1); ?

I would guess so but im not sure, my theory is that 1 would have to evalute to true first, not sure about for(;;);

Share this post


Link to post
Share on other sites
simon10k    220
Is while(true); more efficient than while(1); ?

I would guess so but im not sure, my theory is that 1 would have to evalute to true first, not sure about for(;;); or maybe the bool would have to change to an int type.

Share this post


Link to post
Share on other sites
Roboguy    794
Quote:
Original post by simon10k
Is while(true); more efficient than while(1); ?

I would guess so but im not sure, my theory is that 1 would have to evalute to true first, not sure about for(;;);


No. Even if true was a macro (or even a constant), it would be replaced at compile-time.

Share this post


Link to post
Share on other sites
Conner McCloud    1135

void slow_infinite_loop()
{
double f = 0;
while(f < 1) {
f = rand_float();
f = secant(f) * cosine(f);
f /= 2.0;

//do stuff here
}
}


If the infinite loop is intentional, then chances are it won't get much faster than it already is.

CM

Share this post


Link to post
Share on other sites
Nathan Baum    1027
Sounds like nonsense to me.

Really, it seems like the "infinite" is a complete red herring. Unrolling the loop might improve its performance, depending upon what kind of machine you're running it on. But that's also true of non-infinite loops.

Perhaps the question is designed to test if you recognise BS when you hear it. [smile] Or, alternatively, and perhaps more usefully, to test if you recognise when some part of a problem probably isn't actually relevant, like the infiniteness of the loop probably isn't relevant to its efficiency.

Share this post


Link to post
Share on other sites
Promit    13246
It sounds like a trick question. An infinite loop should eventually compile to:
lbl:
{
// do stuff here
}
goto lbl;

Which maps 1:1 in assembly.

Share this post


Link to post
Share on other sites
void0    202
As far as I know,
while(1) contains an extra 'cmp' in assembly than for(;;).

I've also heard using goto is more efficient (faster?) than for(;;), but I'm not sure.

Share this post


Link to post
Share on other sites
MaulingMonkey    1728
I can't resist a good waste of time sometimes ;-).

A) There is no true infinite loop. Only loops that are meant to be infinite. We'll never reach there, the program will crash/have it's computer die/etc well before we reach infinity.

As such, I can only give a psuedo-infinite loop.

while ( true ) {
...
}


Efficiency metrics:

1) Runtime performance.

Like just about any psuedo-infinite loop, the compiler should optimize it automatically into an unconditional jump.

2) Intent self-documentation

From a glance, we can tell what the conditional will evaluate to (true), and from this deduct how many loops the loop will theoretically execute (an infinite number). It does not depend on knowing language-syntax corner cases ("for (;;)") either.

3) Result self-documentation

Here this lags behind a bit. Although the loop is "infinite", odds are 100+ to 1 that it will still end at some point - server shuts down, needs a hardware upgrade/reboot, backup, or what have you. The mechanisms for exiting are out of channel data, however - exit(), exceptions, returns, and the like - all things which are not eliminated with any other loop either.

This could be made clearer by making them explicit conditions of the loop rather than relying on out-of-channel information, however. The best match in such a case will depend on what we wish to communicate, as well as what types of conditionals we're allowed to submit as "psuedo-infinite".

4) Debug efficiency

Since the loop relys only on standard language features, debuggers should have no problem coping with it's traditional scoping and semantics.

This overanalysis of JUST A #$%(*^#( SIMPLE LOOP brought to you by MaulingMonkey.

Quote:
Original post by void0
As far as I know,
while(1) contains an extra 'cmp' in assembly than for(;;).

I've also heard using goto is more efficient (faster?) than for(;;), but I'm not sure.


Not on any sane compiler, for either.

Share this post


Link to post
Share on other sites
kSquared    1356
Quote:
Original post by MaulingMonkey
I can't resist a good waste of time sometimes ;-).

A) There is no true infinite loop. Only loops that are meant to be infinite. We'll never reach there, the program will crash/have it's computer die/etc well before we reach infinity.

As such, I can only give a psuedo-infinite loop.

while ( true ) {
...
}

That's just silly semantics. A loop whose terminating condition is either nonexistent (e.g. "for (;;) { ... }") or which can never be met (e.g. "while (true) { ... }") is infinite. And if we're going to get bogged down in semantics, then it behooves me to point out that we can never "reach infinity". Infinity is neither a goal you can attain nor a line you can cross.

Pseudo-infinite loops like you mentioned do exist, but they only appear to be infinite and do in fact terminate. For instance, "while (rand.Next() != 0) { ... }" is pseudo-infinite (the expected number of iterations is 232).

Share this post


Link to post
Share on other sites
Evil Steve    2017
It's really whatever you prefer. I always use for(;;) because using any other looping construct (while(true), do..while(1), etc) causes MSVC to complain about contstant expressions. Having said that, the first time I saw for(;;), I didn't have a clue what it was doing. I always think that while(true) is the cleanest and most obvious infinite loop.

Share this post


Link to post
Share on other sites
Bregma    9199
Fact is, you don't need to worry about making your infinite loops more efficient. It's true, it was a concern back in the days of 9-track tape reels where a real programmer knew at least three ways to approach an M-way tape merge with only M-1 tape drives (M >= 3), and knew the difference between 77 and 88 in the data division. These days, however, we can just rely on Moore's law knowing with confidence that in 18 months your infinite loop will complete in just half the time it takes today.

Share this post


Link to post
Share on other sites
cherryhouse    100
Quote:

A) There is no true infinite loop. Only loops that are meant to be infinite. We'll never reach there, the program will crash/have it's computer die/etc well before we reach infinity.


How do you reach infinity?

Share this post


Link to post
Share on other sites
wendigo23    512
Quote:
Original post by cherryhouse
Quote:

A) There is no true infinite loop. Only loops that are meant to be infinite. We'll never reach there, the program will crash/have it's computer die/etc well before we reach infinity.


How do you reach infinity?


With really long arms

Share this post


Link to post
Share on other sites
Zahlman    1682
Quote:
Original post by void0
I've also heard using goto is more efficient (faster?) than for(;;), but I'm not sure.


Maybe the first time K&R wrote the compiler...

Share this post


Link to post
Share on other sites
Timkin    864
lbl: goto lbl;
works for me ;)

As for answering the OP's question, I would answer it with a question: Why would you want to write an "infinite loop".

Timkin

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this