Connecting Tech Pros Worldwide Forums | Help | Site Map

efficient assignment ???

Programmer
Guest
 
Posts: n/a
#1: Jul 22 '05
Is this:

int x;
for (int count=0; count<200; count++)
{
x = someFunc();
anotherFunc(x);
}


more efficient than this:

for (int count=0; count<200; count++)
{
int x = someFunc();
anotherFunc(x);
}

can someone also explain why?
thanks.

Karl Heinz Buchegger
Guest
 
Posts: n/a
#2: Jul 22 '05

re: efficient assignment ???


Programmer wrote:[color=blue]
>
> Is this:
>
> int x;
> for (int count=0; count<200; count++)
> {
> x = someFunc();
> anotherFunc(x);
> }
>
> more efficient than this:
>
> for (int count=0; count<200; count++)
> {
> int x = someFunc();
> anotherFunc(x);
> }
>
> can someone also explain why?
> thanks.[/color]

Try it with your compiler. You can use the timing
functions clock() to figure this one out

eg.

#include <cstdio>
#include <cstdlib>
#include <ctime>

using namespace std;

int main()
{
clock_t start = clock();

// your code goes here

clock_t finish = clock();

double duration = (double)(finish - start) / CLOCKS_PER_SEC;
printf( "%2.f seconds\n", duration );
}

But make sure, that the duration is long enough. Usually just reapeating
what you need to time a few million times makes it long enough, such
that the resotion of clock() doesn't matter any more (In other words:
make sure your program runs at least a few seconds).


--
Karl Heinz Buchegger
kbuchegg@gascad.at
lilburne
Guest
 
Posts: n/a
#3: Jul 22 '05

re: efficient assignment ???




Programmer wrote:
[color=blue]
> Is this:
>
> int x;
> for (int count=0; count<200; count++)
> {
> x = someFunc();
> anotherFunc(x);
> }
>
>
> more efficient than this:
>
> for (int count=0; count<200; count++)
> {
> int x = someFunc();
> anotherFunc(x);
> }
>
> can someone also explain why?
> thanks.[/color]

You'll probably find that for PODs the compiler will optimize example 2
to be similar to example 1. This won't be the same for non POD
variables. I've seen as much as 17% slowdown for code that looked like:

for (int count=0; count<200; count++)
{
myClass a = someFunc();
anotherFunc(a);
}

run the profiler.

Bart Blommerde
Guest
 
Posts: n/a
#4: Jul 22 '05

re: efficient assignment ???


> Is this:[color=blue]
>
> int x;
> for (int count=0; count<200; count++)
> {
> x = someFunc();
> anotherFunc(x);
> }
>
>
> more efficient than this:
>
> for (int count=0; count<200; count++)
> {
> int x = someFunc();
> anotherFunc(x);
> }[/color]

The second format will be optimized by your compiler to the first one.
I'd say the second runs as fast as the first, since declarations don't
need any processing.



regards,
Bart

Phlip
Guest
 
Posts: n/a
#5: Jul 22 '05

re: efficient assignment ???


Programmer wrote:
[color=blue]
> Is this:
>
> int x;
> for (int count=0; count<200; count++)
> {
> x = someFunc();
> anotherFunc(x);
> }
>
>
> more efficient than this:
>
> for (int count=0; count<200; count++)
> {
> int x = someFunc();
> anotherFunc(x);
> }
>
> can someone also explain why?[/color]

The second is more efficient in terms of programming time. The most
important resource to optimize is programmer time. Do not worry about which
statements are more efficient, worry about how likely they are to catch a
bug. The first version is more risky because you might find yourself using x
outside that loop, and not notice that inside the loop x gets changed.

Always give identifiers the narrowest scope possible.

After you write a big program (and all its automated tests), you can time
them to find the real performance bottleneck. Replacing algorithms will have
a much bigger effect on performance than individual integers.

In this specific case, the compiler will most likely optimize. If it puts x
on the stack, x's address reserves when the function enters, as if x had
been declared outside the loop. If it puts x into a register, then it
doesn't reserve any stack. You will never be able to time a difference
between these minor adjustments.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces


Victor Bazarov
Guest
 
Posts: n/a
#6: Jul 22 '05

re: efficient assignment ???


Programmer wrote:[color=blue]
> Is this:
>
> int x;
> for (int count=0; count<200; count++)
> {
> x = someFunc();
> anotherFunc(x);
> }
>
>
> more efficient than this:
>
> for (int count=0; count<200; count++)
> {
> int x = someFunc();
> anotherFunc(x);
> }
>[/color]

Both are less efficient than

for (int count = 0; count < 200; ++count)
anotherFunc(someFunc());

V
Rolf Magnus
Guest
 
Posts: n/a
#7: Jul 22 '05

re: efficient assignment ???


Victor Bazarov wrote:
[color=blue]
> Programmer wrote:[color=green]
>> Is this:
>>
>> int x;
>> for (int count=0; count<200; count++)
>> {
>> x = someFunc();
>> anotherFunc(x);
>> }
>>
>>
>> more efficient than this:
>>
>> for (int count=0; count<200; count++)
>> {
>> int x = someFunc();
>> anotherFunc(x);
>> }
>>[/color]
>
> Both are less efficient than
>
> for (int count = 0; count < 200; ++count)
> anotherFunc(someFunc());[/color]

I'd expect all three to be the same, or at least not significantly
different on any real-world compiler.

Niklas Borson
Guest
 
Posts: n/a
#8: Jul 22 '05

re: efficient assignment ???


Victor Bazarov <v.Abazarov@comAcast.net> wrote in message news:<4bKUc.56$Ae.43@newsread1.dllstx09.us.to.veri o.net>...
[quotes snipped][color=blue]
> Both are less efficient than
>
> for (int count = 0; count < 200; ++count)
> anotherFunc(someFunc());[/color]

Are you sure? It seems reasonable to expect an optimizing compiler
to generate identical object code for all three versions. VC does,
for example.
Victor Bazarov
Guest
 
Posts: n/a
#9: Jul 22 '05

re: efficient assignment ???


Niklas Borson wrote:[color=blue]
> Victor Bazarov <v.Abazarov@comAcast.net> wrote in message news:<4bKUc.56$Ae.43@newsread1.dllstx09.us.to.veri o.net>...
> [quotes snipped]
>[color=green]
>>Both are less efficient than
>>
>> for (int count = 0; count < 200; ++count)
>> anotherFunc(someFunc());[/color]
>
>
> Are you sure? It seems reasonable to expect an optimizing compiler
> to generate identical object code for all three versions. VC does,
> for example.[/color]

Of course I am sure. How many fewer characters did I have to type
to get to the same object code? See?
Risto Lankinen
Guest
 
Posts: n/a
#10: Jul 22 '05

re: efficient assignment ???



"Bart Blommerde" <bart@ilse.net> wrote in message
news:41236f62$0$32569$6c56d894@diablo.nl.easynet.n et...[color=blue]
>
> The second format will be optimized by your compiler to the first one.
> I'd say the second runs as fast as the first, since declarations don't
> need any processing.[/color]

Aren't these two sentences in slight logical conflict? I mean, if
one is as fast as the other, what would be the reason for the
optimizer to asymmetrically convert the second to the first one?

- Risto -


Thomas Matthews
Guest
 
Posts: n/a
#11: Jul 22 '05

re: efficient assignment ???


Niklas Borson wrote:
[color=blue]
> Victor Bazarov <v.Abazarov@comAcast.net> wrote in message news:<4bKUc.56$Ae.43@newsread1.dllstx09.us.to.veri o.net>...
> [quotes snipped]
>[color=green]
>>Both are less efficient than
>>
>> for (int count = 0; count < 200; ++count)
>> anotherFunc(someFunc());[/color]
>
>
> Are you sure? It seems reasonable to expect an optimizing compiler
> to generate identical object code for all three versions. VC does,
> for example.[/color]

Victor's example should compile faster (but whether
that's observable or not is another matter).

One issue with Victor's example is that the return
value from someFunc is hidden from a debugger and
hard to see (from most of them that I used). When
testing the code, I prefer to use separate
assignments. After the code works, I'll convert
it to Victor's example, if and only if the readability
is greater.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book

Niklas Borson
Guest
 
Posts: n/a
#12: Jul 22 '05

re: efficient assignment ???


Victor Bazarov <v.Abazarov@comAcast.net> wrote in message news:<nnRUc.69$Ae.6@newsread1.dllstx09.us.to.verio .net>...[color=blue]
> Niklas Borson wrote:[color=green]
> > Victor Bazarov <v.Abazarov@comAcast.net> wrote in message news:<4bKUc.56$Ae.43@newsread1.dllstx09.us.to.veri o.net>...
> > [quotes snipped]
> >[color=darkred]
> >>Both are less efficient than
> >>
> >> for (int count = 0; count < 200; ++count)
> >> anotherFunc(someFunc());[/color]
> >
> >
> > Are you sure? It seems reasonable to expect an optimizing compiler
> > to generate identical object code for all three versions. VC does,
> > for example.[/color]
>
> Of course I am sure. How many fewer characters did I have to type
> to get to the same object code? See?[/color]

Fair enough. :-)
Niklas Borson
Guest
 
Posts: n/a
#13: Jul 22 '05

re: efficient assignment ???


Thomas Matthews <Thomas_MatthewsSpitsOnSpamBots@sbcglobal.net> wrote in message news:<Am2Vc.5112$FV3.1413@newssvr17.news.prodigy.c om>...[color=blue]
> Niklas Borson wrote:
>[color=green]
> > Victor Bazarov <v.Abazarov@comAcast.net> wrote in message news:<4bKUc.56$Ae.43@newsread1.dllstx09.us.to.veri o.net>...
> > [quotes snipped]
> >[color=darkred]
> >>Both are less efficient than
> >>
> >> for (int count = 0; count < 200; ++count)
> >> anotherFunc(someFunc());[/color]
> >
> >
> > Are you sure? It seems reasonable to expect an optimizing compiler
> > to generate identical object code for all three versions. VC does,
> > for example.[/color]
>
> Victor's example should compile faster (but whether
> that's observable or not is another matter).
>
> One issue with Victor's example is that the return
> value from someFunc is hidden from a debugger and
> hard to see (from most of them that I used). When
> testing the code, I prefer to use separate
> assignments. After the code works, I'll convert
> it to Victor's example, if and only if the readability
> is greater.[/color]

And of course, what one considers more readable is a
matter of style and opinion.

I used to favor really dense code. Over time, as
screens have gotten larger and my functions smaller,
I have come to prefer a less dense style. It's still
a judgment call in each case, but I am now more
likely than before to break up complex expressions
and assign intermediate results to named variables.
Closed Thread