Compiling with -O option gives different running time!

Discussion in 'C Programming' started by aamircheema@gmail.com, Jun 13, 2006.

  1. Guest

    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
    , Jun 13, 2006
    #1
    1. Advertising

  2. Guest

    Re: Compiling with -O option gives different running time!

    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
    , Jun 13, 2006
    #2
    1. Advertising

  3. Chris Dollin Guest

    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/
    Chris Dollin, Jun 13, 2006
    #3
  4. SuperKoko Guest

    Re: Compiling with -O option gives different running time!

    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).
    SuperKoko, Jun 13, 2006
    #4
  5. Re: Compiling with -O option gives different running time!

    "SuperKoko" <> wrote in message
    news:...
    >
    > 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
    Stephen Sprunk, Jun 13, 2006
    #5
  6. Guest

    Re: Compiling with -O option gives different running time!

    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
    , Jun 13, 2006
    #6
  7. Guest

    Re: Compiling with -O option gives different running time!

    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
    , Jun 13, 2006
    #7
  8. Re: Compiling with -O option gives different running time!

    <> wrote in message
    news:...
    > 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
    Stephen Sprunk, Jun 13, 2006
    #8
  9. CBFalconer Guest

    Re: Compiling with -O option gives different running time!

    Stephen Sprunk wrote:
    > "SuperKoko" <> 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, Jun 13, 2006
    #9
  10. CBFalconer Guest

    Re: Compiling with -O option gives different running time!

    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/>
    CBFalconer, Jun 13, 2006
    #10
  11. Re: Compiling with -O option gives different running time!

    "CBFalconer" <> wrote in message
    news:...
    > 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
    Stephen Sprunk, Jun 13, 2006
    #11
  12. Guest

    Re: Compiling with -O option gives different running time!

    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
    , Jun 13, 2006
    #12
  13. Guest

    Re: Compiling with -O option gives different running time!

    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
    , Jun 13, 2006
    #13
  14. CBFalconer Guest

    Re: Compiling with -O option gives different running time!

    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
    CBFalconer, Jun 13, 2006
    #14
  15. Re: Compiling with -O option gives different running time!

    CBFalconer <> 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) <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.
    Keith Thompson, Jun 13, 2006
    #15
  16. Guest

    Re: Compiling with -O option gives different running time!

    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 :)
    , Jun 13, 2006
    #16
  17. SuperKoko Guest

    Re: Compiling with -O option gives different running time!

    Stephen Sprunk wrote:
    > "SuperKoko" <> 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, Jun 14, 2006
    #17
  18. SuperKoko Guest

    Re: Compiling with -O option gives different running time!

    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.
    SuperKoko, Jun 14, 2006
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Will
    Replies:
    1
    Views:
    367
    Paul Lutus
    Sep 2, 2004
  2. Julien ROUZIERES

    g++ -pg option and -shared option

    Julien ROUZIERES, Dec 21, 2004, in forum: C++
    Replies:
    1
    Views:
    700
    GianGuz
    Dec 21, 2004
  3. Christian Seberino
    Replies:
    3
    Views:
    1,157
    Christian Seberino
    Feb 5, 2004
  4. flamesrock
    Replies:
    8
    Views:
    430
    Hendrik van Rooyen
    Nov 24, 2006
  5. Replies:
    6
    Views:
    846
    Robert
    Mar 8, 2006
Loading...

Share This Page