Why are effect-less functions executed?

Question

All the languages I know of would execute something like:

i = 0
while i < 100000000
    i += 1

..and you can see it take a noticeable amount of time to execute.

Why though, do languages do this? The only effect this code will have is taking time.

edit: I mean inside a function which is called

function main(){
    useless()
}
function useless(){
    i = 0
    while i < 100000000
        i += 1
}

Answer 1

In general, its hard (that is, undecidable) to prove if something is a silly busy loop (that could be optimized out) or an infinite loop (that cannot be optimized out withuot changing the meaning of the program). Does the following code loop forever or does it stop?

var n = //some positive integer
while(n != 1){
   if(n % 2 == 0)
      n = n/2;
   else
      n = 3*n+1
}

Because of this complexity, most programming languages give up on trying to reason too much about the program and therefore pass the responsibility of not running silly busy loops back to the programmer.

Answer 2

Get a better implementation. Many C++ compilers I know would remove much more complex code with no side effects than this.

Answer 3

This code may do nothing as you think it does, but what if, taking C# as example, I had overloaded the + operator.

public static int operator +(int one, int two) {/* implement crazy operation here */}

In the overload, I'd generate a frame and scale the operator to sync for 60fps.

This "useless" loop has now become a game that stops at the 100000000th frame. Not so useless heh?

Your inability to clearly define "useless code" is why the compiler can't deal with it.

Answer 4

Commonly (and probably the only valid use for this) used in micro-controllers to control timing accurately, however most likely to be written in Assembler (or inline assembler in a C programmer) as the programmer then has absolute control over the instructions used, hence the time taken.

Answer 5

There's 2 things to mention here. The first is that, many compilers as DeadMG said might optimize out code like this. As you probably know, if the point of the code was to take time, then this is inaccurate and dependent on the frequency of the processor.

The second thing to point out is your mentioning of "effect-less". It might not be what you mean, but many devs (especially those who are fans of functional programming, and its associated paradigms) advocate that you should avoid side-effects almost entirely - that is to say, have no external state. Generally speaking, programming in this way requires that you return some value from every function, thus it doesn't apply to the trivial example that you posted - but does to less-trivial examples.

Answer 6

To create an extreme loading condition

One use of the Unix yes application, which uses a similar loop construct, is to exercise the CPU to simulate high load.

It also provides a continuous "y" output for use with responses to older versions of Unix command lines.

I realise that the yes application is providing a measurable side-effect and so would not get optimised away, but the point I'm making is that fast, tight loops serve as useful load tests.

Answer 7

As @BillMichell suggests in his comment, the point is to consume time, assumably to allow something else to happen. Most modern languages have a better way to do this--telling the thread or process to sleep or wait for a specified period of time. In the bad old days, that wasn't an option.

Answer 8

2 reasons first is that to fully remove all dead code compilers would need to solve the halting problem which is impossible and many compilers don't even try

second sometimes the programmer want a delay/busy loop there for various reasons (including simply slowing everything down so when Mr. Boss tells you to speed it up you can remove a 0 from the upper bound)

Answer 9

First languages have most probably nothing to do with the issue. Definitions of languages give the observable behavior and they don't consider duration as observable behavior excepted for very special purpose functions.

Thus you are speaking about implementation choice.

As a documented case, let's look at gcc.

In early gcc documentation, they stated that they purposely didn't remove empty loops as they were most probably there for a timing purpose.

In newer one, they now state they have reversed their decision as empty loops are now most often due to other optimizations (which may remove all existing content) and they warn that empty loops will be removed if gcc is able to show that they will terminate.