Compiling with -O option gives different running time!

[aamircheema]

Hi,

When I compile my program adding -O option, the running time of my
program is much smaller. For example if i compile my program like this

g++ -Wall -g prog2.cc avltree.cc cells_list.cc hashsep_query.cc
hashsep_point.cc int_list.cc loadavltree.cc -o p2 -lm

its run time is around 12 seconds.

but if i compile it with

g++ -Wall -g -O prog2.cc avltree.cc cells_list.cc hashsep_query.cc
hashsep_point.cc int_list.cc loadavltree.cc -o p2 -lm

its run time is around 7 seconds.
I am really new at C++ so can't figure it out why is it so different.
Any idea?

Thanks,
Aamir

[tomstdenis]

[e-mail] wrote:

Hi,

When I compile my program adding -O option, the running time of my
program is much smaller. For example if i compile my program like this

<snip>

run

man gcc

And then search for "-O"

Tom

[Chris Dollin]

aa*********@gmail.com wrote:

When I compile my program adding -O option, the running time of my
program is much smaller. For example if i compile my program like this

g++ -Wall -g prog2.cc avltree.cc cells_list.cc hashsep_query.cc
hashsep_point.cc int_list.cc loadavltree.cc -o p2 -lm
Urm ... this is off-topic twice (C++, and implementation-specific).
its run time is around 12 seconds.

but if i compile it with

g++ -Wall -g -O prog2.cc avltree.cc cells_list.cc hashsep_query.cc
hashsep_point.cc int_list.cc loadavltree.cc -o p2 -lm

If you don't know what -O is for, why did you add it to the command line?

--
Chris "and if you did, why are you asking?" Dollin
"We did not have time to find out everything we wanted to know." /A Clash of Cymbals/

[SuperKoko]

aa*********@gmail.com wrote:

Hi,

When I compile my program adding -O option, the running time of my
program is much smaller. For example if i compile my program like this

g++ -Wall -g prog2.cc avltree.cc cells_list.cc hashsep_query.cc
hashsep_point.cc int_list.cc loadavltree.cc -o p2 -lm

its run time is around 12 seconds.

but if i compile it with

g++ -Wall -g -O prog2.cc avltree.cc cells_list.cc hashsep_query.cc
hashsep_point.cc int_list.cc loadavltree.cc -o p2 -lm

its run time is around 7 seconds.
I am really new at C++ so can't figure it out why is it so different.
Any idea?

-O is the "optimization compiler flag".
With that... the compilation time is a bit longer, but executables are
smaller and run much faster.
-O2 gives even better optimizations.
-O3 gives yet even better optimizations, but executables greater (in
kilobytes) than with -O2.

When releasing a program you should always compile it with -O2 or -O3
(and probably -fomit-frame-pointer).

[Stephen Sprunk]

"SuperKoko" <ta*******@yahoo.fr> wrote in message
news:11**********************@h76g2000cwa.googlegr oups.com...

aa*********@gmail.com wrote:

When I compile my program adding -O option, the running time of my
program is much smaller.

What did you expect it to do? Making your program run faster is the entire
point of the -O option (in GCC at least, but also for most other compilers).
-O is the "optimization compiler flag".
With that... the compilation time is a bit longer, but executables are
smaller and run much faster.
-O2 gives even better optimizations.
-O3 gives yet even better optimizations, but executables greater (in
kilobytes) than with -O2.

When releasing a program you should always compile it with -O2 or -O3
(and probably -fomit-frame-pointer).

Unless, of course, your program no longer gives correct output with those
optimization levels due to compiler bugs, or you care about the ability to
debug problems in your own code. Many, many vendors ship unoptimized (or
minimally optimized) code because it works better and is easier to
test/debug. There are few programs that are so performance-critical that
the risk of -O3 and -fomit-frame-pointer is worth the gain.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
--
Posted via a free Usenet account from http://www.teranews.com

[aamircheema]

Thanks everybody. It was helpful.

Actually I had implemented an algorithm and when I compile my proram
with -O it is much faster whereas when I compile the code of my
comparators with -O it doesn't have any effect on their running time.
What may be the reason?
Is it fair to compare the running time using optimization?
As suggested, optimization may lead to wrong output so if this happen
does this mean that their was something wrong in implementation ? or
wat?

Thanks again for your help.

Aamir

[tomstdenis]

aa*********@gmail.com wrote:

Thanks everybody. It was helpful.

Actually I had implemented an algorithm and when I compile my proram
with -O it is much faster whereas when I compile the code of my
comparators with -O it doesn't have any effect on their running time.
What may be the reason?
I don't think you understand, even superficially what a compiler is.
That is your first problem. You don't need to be writing the next GCC
to know the jist of optimization.
Is it fair to compare the running time using optimization?
Usually. Could also compare size.
As suggested, optimization may lead to wrong output so if this happen
does this mean that their was something wrong in implementation ? or
wat?

9 times out of 10 it means your program is broken and that you have
something that exploits it [like variables on the stack...]

Tom

[Stephen Sprunk]

<aa*********@gmail.com> wrote in message
news:11**********************@u72g2000cwu.googlegr oups.com...

Thanks everybody. It was helpful.

Actually I had implemented an algorithm and when I compile my proram
with -O it is much faster whereas when I compile the code of my
comparators with -O it doesn't have any effect on their running time.
What may be the reason?
That is a bit strange; I've never run across code that doesn't improve _at
all_ when optimized, but I'm sure it's possible.

If one writes the most obvious (and correct) code to solve a problem, it
will likely run slowly without optimization, but when optimization is
enabled the compiler should be able to make it go much faster. If one
writes very tight, slightly incorrect code, the compiler may not be able to
speed it up without breaking it, and so it can't help.

As the saying goes, "it's a lot easier to make correct code fast than it is
to make fast code correct."
Is it fair to compare the running time using optimization?
Depends why you're comparing. In most cases, software is compared with the
highest optimization level that results in correct code.
As suggested, optimization may lead to wrong output so if this happen
does this mean that their was something wrong in implementation ? or
wat?

It depends. If the code is correct, odds are wrong output is caused by a
compiler bug; however, unless one is a very good coder, there's a much
higher chance that the code was not correct in the first place and the more
aggressive optimization levels merely exposed bugs that were there all
along.

If you don't know how to determine which of those applies to your code,
assume that the bug is yours, not the compiler's.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Stephen Sprunk wrote:

"SuperKoko" <ta*******@yahoo.fr> wrote in message
.... snip ...

-O is the "optimization compiler flag".
With that... the compilation time is a bit longer, but executables
are smaller and run much faster.
-O2 gives even better optimizations.
-O3 gives yet even better optimizations, but executables greater
(in kilobytes) than with -O2.

When releasing a program you should always compile it with -O2
or -O3 (and probably -fomit-frame-pointer).

Provided you test it thusly. You can also use -Os to optimize code
size.

Unless, of course, your program no longer gives correct output
with those optimization levels due to compiler bugs, or you care
about the ability to debug problems in your own code. Many, many
vendors ship unoptimized (or minimally optimized) code because it
works better and is easier to test/debug. There are few programs
that are so performance-critical that the risk of -O3 and
-fomit-frame-pointer is worth the gain.

When something fails under higher optimization levels it is often
an indication of faulty coding triggering undefined or
implementation defined behaviour. This is more likely than a
compiler bug, although the extra compilation effort increases the
likelihood of exposing a compiler insect.

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

[CBFalconer]

aa*********@gmail.com wrote:

Actually I had implemented an algorithm and when I compile my proram
with -O it is much faster whereas when I compile the code of my
comparators with -O it doesn't have any effect on their running time.
What may be the reason?
Is it fair to compare the running time using optimization?
As suggested, optimization may lead to wrong output so if this happen
does this mean that their was something wrong in implementation ? or
wat?

You should always include context so that your article can stand by
itself. If you are using a google access that has not fixed the
reply bug see below for means to rectify that. Remember, google is
NOT usenet, it is only a flawed interface to usenet.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[Stephen Sprunk]

"CBFalconer" <cb********@yahoo.com> wrote in message
news:44***************@yahoo.com...

Stephen Sprunk wrote:

Unless, of course, your program no longer gives correct output
with those optimization levels due to compiler bugs, or you care
about the ability to debug problems in your own code. Many, many
vendors ship unoptimized (or minimally optimized) code because it
works better and is easier to test/debug. There are few programs
that are so performance-critical that the risk of -O3 and
-fomit-frame-pointer is worth the gain.

When something fails under higher optimization levels it is often
an indication of faulty coding triggering undefined or
implementation defined behaviour. This is more likely than a
compiler bug, although the extra compilation effort increases the
likelihood of exposing a compiler insect.

And I did say that in a later post. In ten years of working with GCC, I've
found exactly one bug in -O3, and it was already fixed in a more recent
version. However, I'm a hobbyist and not a professional coder; YMMV.

The real issue is that higher optimization makes debugging _your_ code much
more difficult, and -fomit-frame-pointer can make it tough to figure out
where to look. If -O3 exposes more of my bugs, that's great, but excessive
optimization may make it impossible for me to isolate them. One of the
tribulations of optimization is that even including test code to find bugs
may change the resulting code so that the bug no longer happens, and
stepping through the code in a debugger is mind-boggling because it no
longer remotely resembles what you wrote.

This is why, as I said, many commercial software vendors simply don't use
high (or any) optimization on what they ship. (Plus they don't pay the cost
of users needing faster machines to run unoptimized code.)

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
--
Posted via a free Usenet account from http://www.teranews.com

[tomstdenis]

CBFalconer wrote:

When releasing a program you should always compile it with -O2
or -O3 (and probably -fomit-frame-pointer).

Provided you test it thusly. You can also use -Os to optimize code
size.

Splitting hairs [I'm sorry, I know *you* know but for the rest of the
audience...]

-Os doesn't mean "optimize for size" it means "perform optimizations
not likely to increase the size" so things like GCSE, strength
reduction, other inductions. On the other hand, it won't do things
like loop unrolling or function inlining.

It won't modularize your code [at least not that I know of] so if you
have a common body of code repeated literally throughout the code -Os
won't help.

Generally -Os and -O2 produce similar footprints on x86_32 platforms
from what I've seen.

Also on some code snippets -O3 can be SLOWER than -O2. So it always
pays to be able to benchmark what you are doing.

Tom

[tomstdenis]

Stephen Sprunk wrote:

And I did say that in a later post. In ten years of working with GCC, I've
found exactly one bug in -O3, and it was already fixed in a more recent
version. However, I'm a hobbyist and not a professional coder; YMMV.
Anyone who has really worked GCC has found at least one bug or two.
[mmm my precious bugs...]. hehehehe.

-O3 on x86 is generally fairly stable in the 3.4 and as far as I can
tell 4.1 trees. 3.2 and 3.0 sucked for me and 3.3 is a bit flaky.
The real issue is that higher optimization makes debugging _your_ code much
more difficult, and -fomit-frame-pointer can make it tough to figure out
where to look. If -O3 exposes more of my bugs, that's great, but excessive
optimization may make it impossible for me to isolate them. One of the
tribulations of optimization is that even including test code to find bugs
may change the resulting code so that the bug no longer happens, and
stepping through the code in a debugger is mind-boggling because it no
longer remotely resembles what you wrote.
Usually it can still tell at least what access cause the problem [e.g.
segfaults]. You're right though. It makes stepping the code
impossible and stack traces impossible to form.
This is why, as I said, many commercial software vendors simply don't use
high (or any) optimization on what they ship. (Plus they don't pay the cost
of users needing faster machines to run unoptimized code.)

Wrong though. Many commercial vendors tune down the optimizations
because their buggy code won't run at higher levels.

I've had numerous bugs in my LT projects traceable to stack overflows
that would only show up at -O2 or higher. So my -O0 debug builds would
run fine and the -O3 would fail.

Of course I don't ship code that can't build in O2, Os and O3. But the
folk I work with routinely have makefiles hacked with "use -O0 for this
file" to get around bugs in their code, the compiler or both. It has
nothing to do with debugging because they have -g3 builds for that.

Tom

[Keith Thompson]

CBFalconer <cb********@yahoo.com> writes:
[...]

When something fails under higher optimization levels it is often
an indication of faulty coding triggering undefined or
implementation defined behaviour. This is more likely than a
compiler bug, although the extra compilation effort increases the
likelihood of exposing a compiler insect.

<QUIBBLE>
I think it's more likely to be undefined behavior than
implementation-defined behavior. If implementation-defined behavior
(which the implementation must document) changes with the optimization
level, it's probably a bug in the compiler -- unless the compiler's
documentation says that the behavior changes with optimization level.
</QUIBBLE>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[CBFalconer]

to********@gmail.com wrote:

Stephen Sprunk wrote:
.... snip ...

This is why, as I said, many commercial software vendors simply
don't use high (or any) optimization on what they ship. (Plus
they don't pay the cost of users needing faster machines to run
unoptimized code.)

Wrong though. Many commercial vendors tune down the optimizations
because their buggy code won't run at higher levels.

I've had numerous bugs in my LT projects traceable to stack
overflows that would only show up at -O2 or higher. So my -O0
debug builds would run fine and the -O3 would fail.

Of course I don't ship code that can't build in O2, Os and O3.
But the folk I work with routinely have makefiles hacked with
"use -O0 for this file" to get around bugs in their code, the
compiler or both. It has nothing to do with debugging
because they have -g3 builds for that.

Congratulations. You have matured greatly in the past two years
and no longer generate an urge to plonk. This is partly for the
benefit of those who still have you in their plonk files.

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

[tomstdenis]

CBFalconer wrote:

Of course I don't ship code that can't build in O2, Os and O3.
But the folk I work with routinely have makefiles hacked with
"use -O0 for this file" to get around bugs in their code, the
compiler or both. It has nothing to do with debugging
because they have -g3 builds for that.

Congratulations. You have matured greatly in the past two years
and no longer generate an urge to plonk. This is partly for the
benefit of those who still have you in their plonk files.

I haven't matured, I just haven't pissed you off lately.

I didn't do jack squat then for the approval of others [re: other
people suck] and I still don't.

It just happens my exploits are exploitable [e.g. my LT projects] so
people put up with the shit I pull. Which is good for me cuz it's fun
and gives me something to do other than watch day time television.

Tom, back in your plonkfile I go I suspect :-)

[SuperKoko]

Stephen Sprunk wrote:

"SuperKoko" <ta*******@yahoo.fr> wrote in message

When releasing a program you should always compile it with -O2 or -O3
(and probably -fomit-frame-pointer).

Unless, of course, your program no longer gives correct output with those
optimization levels due to compiler bugs, or you care about the ability to
debug problems in your own code. Many, many vendors ship unoptimized (or
minimally optimized) code because it works better and is easier to
test/debug. There are few programs that are so performance-critical that
the risk of -O3 and -fomit-frame-pointer is worth the gain.

Or a progam bug due to the fact that the programmer doesn't know well
the whole ISO/IEC 14882:2003 standard. ;)
Things like converting an "unsigned*" to a "unsigned short*" and using
the "unsigned short*" to access the data which contains unsigned
integers... With no-aliasing optimizations, it might behave differently
than the programmer expected (and don't say that the compiler is buggy
here).

[SuperKoko]

aa*********@gmail.com wrote:

Thanks everybody. It was helpful.

Is it fair to compare the running time using optimization?
As suggested, optimization may lead to wrong output so if this happen
does this mean that their was something wrong in implementation ? or
wat?

Except if you intend to release your program without optimizations, it
is very unfair to compare speed without optimizations.
An optimizations level of 1 is the minimum if you want to compare the
real speed that the program should have with a normal compiler (there
are even compilers such as Borland C++ which always write a code with
optimizations, even if the compiler is not a good optimizer).

IMHO, it is better to use a very stable, perfectly debugged, old
version of a compiler, and compile with optimizations, than using the
latest version, and compile without optimizations.
GCC without any optimization produce the worst code I have ever seen
for a C++ compiler (the intent is that the code behaves exactly as a
naive programmer expects).
Even Turbo C++ 1 gives much better results.