«

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

aamirche...@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

<snip>

run

man gcc

And then search for "-O"

Tom

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/

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" <> wrote in message
news: oups.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

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

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

<> wrote in message
news: 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

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

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/>