Thread: Why isn't this C program optimized?

Maybe it's spending 24 seconds scratching its head wondering why you're doing a loop with the statement T+=0.0 in the first place.

You can examine the assembler code if you're really curious. Compile with the -S option for gcc to do so.

[edit] I don't think the designers of gcc spent much time optimising statements like that. Who uses +=0 anyway? [/edit]

Originally Posted by dwks

Who uses +=0 anyway?

http://en.wikipedia.org/wiki/Sanity_check ?

Originally Posted by hzmonte

3. If I remove the last printf(), the timings do not change. I thought without printing T, the computation of T is irrelevant because T's value will never be used. So gcc should have optimized away the entire computation!

Why on earth should it do that?


Quzah.

Originally Posted by quzah

Why on earth should it do that?


Quzah.

Because the value of T has no effect on the output of the program. If the variable has no effect, why should the processor be bothered in calculating it?
(Better: why do you have an unused variable in your code.)

There was a thread awhile ago where a guy had this problem. His whole loop was being optimized into the void by the compiler. Rightly so, however.

This code seems to exhibit such behavior: (Disclaimer: I haven't checked the assembly.)

Code:

#include <stdio.h>
#include <sys/timeb.h>

int main()
{
	double d = 0, timetotal;
	int x;
	struct timeb t1, t2;

	ftime(&t1);

	for(x = 0; x < 50000000; ++x)
	{
		d += 1.278197234;
		d *= 0.982841924;
		d /= 1.848739275;
		d += 1.278197234;
		d *= 0.982841924;
		d /= 1.848739275;
	}

	ftime(&t2);

	timetotal = (double) t2.time + (double) t2.millitm / 1000.0;
	timetotal -= (double) t1.time + (double) t1.millitm / 1000.0;

	//printf("%g\n", d);
	printf("Runtime: %6.3g", timetotal);

	return 0;
}

Compiled using "gcc -O2 -o opti.exe opti.c", with and without the printf(), the one with the printf() takes 12-17 seconds to run, whereas without, it takes ~0.2 seconds to run.

To the OP: While I nod my head in agreement with SlyMaelstrom, worry about optimizations when they're needed. The compiler's optimizations are there to help you - better algorithms and coding practices will (usually) trump anything a compiler can eek out. If something is running too slow, find the bottleneck, and see what you can do to fix it.

To me, "optimization" is usually, "Holy cow, this thing runs a lot quicker when we're not doing debug versions! (And it's smaller to boot!)"

Originally Posted by Cactus_Hugger

Because the value of T has no effect on the output of the program. If the variable has no effect, why should the processor be bothered in calculating it?
(Better: why do you have an unused variable in your code.)

Keep your statements straight. It isn't unused. It is used inside the loop. You don't say a variable is considered unused just because you haven't printed or displayed. Otherwise, all loop counters would be considered unused by your definition, because you aren't printing them any place. See how stupid that is?

Originally Posted by Cactus_Hugger

There was a thread awhile ago where a guy had this problem. His whole loop was being optimized into the void by the compiler. Rightly so, however.

People actually use loops to intentionally delay a program occasionally. It's not as common as it once was, but it is done occasionally.


Quzah.

>It takes about 30 seconds.
Here's my results:
Without -O3 -> 52 seconds
With -O3 -> 9 seconds

"Unread" then, quzah. Cactus_Hugger is right. The C++ standard says that the semantics of a program are defined by the calls to I/O functions it makes and the sequence of reads and writes of volatile variables, but not the timing of either. Thus, any amount of reads and writes to a non-volatile variable will not, by themselves, influence the semantics of the program, and the compiler is free to do whatever it wants with these instructions. Including, of course, simply removing them.

Originally Posted by CornedBee

The C++ standard says that the semantics of a program are defined by the calls to I/O functions it makes and the sequence of reads and writes of volatile variables, but not the timing of either.

Who the ........ are you again? Oh, wait, a better question should be: "Why the ........ should I care what the C++ standard says?" This is the C forum.


Quzah.

Oops. Whatever. C standard probably says the same thing.

Actually it's close. However, the standard doesn't say optimization has to take effect. It, from everything I'm seeing, says "optimizaiton may..." do this or that.

Which is why I said, "why should it"? It doesn't have to.

However, since this has been drug out so much, and I've nothing better to do than to drag it out more...

We don't actually see the declaration of any of those varaiables. Now, had he actually posted the code in its entirety, we might be at a different conclusion. Or rather, I might be agreeing here. However, because I like to argue points of the standard, we don't know how any of those variables are declared. They could be volatile.

In which case, they won't be optimized out, even if they're never part of any output. Also, there are fun little things with optimization, where if it can't be sure, it won't remove it.

Anyway, the key with optimization is the word may.


Quzah.

Oh yeah, they just might be volatile

Why, though? Well, because any good compiler should have good enough flow analysis to do it, of course!

Originally Posted by CornedBee

Oops. Whatever. C standard probably says the same thing.

FWIW