|
From: <or...@vp...> - 2003-08-04 14:20:12
|
Hi!
Now, I have a question.
I need to do heavy optimizations in the project I am working on, and I
am asking you, whether will I gain any speedup by optimizing loops. I am
interested in the for loop exactly. Let's take this example:
for(i=0;i<getint();i++){
/* ... */
}
Would it worth it to take that getint() into an outer variable, and only
use that in the conditional, like this:
int c = getint();
for(i=0;i<c;i++){
/* ... */
}
Will this give me any speedup? I am interested in particular, is for
going to call getint() EVERY time in the first case (on top), or will it
do it only once? I think the second case is better, am I right?
Allright, that was my first question, here is the second:
What is the case, if the conditional is a KNOWN value. Something, like a
macro. Here is the example:
#define GETINT (10*5)
for(i=0;i<GETINT;i++){
/* ... */
}
I suppose, this will be optimised by the compiler, and this can even be
unrolled, am I right?
Thanks in advance.
--
Greetings,
Balázs
|
|
From: Vale G. <val...@at...> - 2003-08-04 18:25:08
|
Balázs -
> I need to do heavy optimizations in the project I am working on, and I am
asking you, whether will I gain any speedup by optimizing loops.
> for(i=0;i<getint();i++){...}
The only way to know for sure whether and where you need to optimize the code is
to run the profile program on it.
That said, I would suggest changing the increment operator from postfix to
prefix.
for (i=0; i<getint(); ++i)
See:
http://www.tantalon.com/pete/cppopt/asyougo.htm
http://www.devx.com/cplus/Article/16328/0/page/4
It probably doesn't matter much; your compiler may already be optimizing this
code for you.
Charles
|
|
From: Abhijit S. <mu...@gm...> - 2003-08-04 18:44:04
|
Hello, Oroszi.
> for(i=0;i<getint();i++){
> /* ... */
> }
>
> Would it worth it to take that getint() into an outer variable, and only
> use that in the conditional, like this:
>
> int c = getint();
> for(i=0;i<c;i++){
> /* ... */
> }
>
> Will this give me any speedup?
I don't know about the working of gcc, so this I don't know if this will be
optimized. However, there's no loss in doing this, and I guess you should
(so that even if gcc, or whatever compiler you want to move it onto doesn't
optimize it, you get the fastest code). Without optimization, the second
will definitely be better than the first, since in case 1, on every
iteration, there's the overhead of the function call, and in case 2, that is
eliminated.
> I am interested in particular, is for
> going to call getint() EVERY time in the first case (on top), or will it
> do it only once? I think the second case is better, am I right?
I think I answered that already.
> Allright, that was my first question, here is the second:
> What is the case, if the conditional is a KNOWN value. Something, like a
> macro. Here is the example:
>
> #define GETINT (10*5)
>
> for(i=0;i<GETINT;i++){
> /* ... */
> }
There is no need for optimization at all here, because the compiler will see
this as:
for(i = 0; i < (10*5); i++) { [whatever] }
So that's a constant already. The unrolling may be done by the compiler
itself (there was a flag -funroll-loops, I'm not sure, you should check that
out).
The postfix/prefix conversion indicated by Charles will help only for
user-defined classes, not for primitives. Also, I think gcc optimizes this
automatically.
This might give you more info:
http://computational-battery.org/Tools/gcc-opt-guide.html
There are a couple of links at the bottom of the page that you should read,
too.
--
Abhijit Shylanath
Homepage: http://mudeth.tripod.com/
|
|
From: <or...@vp...> - 2003-08-04 19:45:11
|
Abhijit Shylanath wrote: > This might give you more info: > http://computational-battery.org/Tools/gcc-opt-guide.html > > There are a couple of links at the bottom of the page that you should read, > too. Thanks for all your help both. I apreciate it. However, I use C only now. BTW, could you look at my second mail also. That would be very great for me. Thanks! -- Greetings, Balázs |
|
From: Ioannis V. <iv...@em...> - 2003-08-04 22:49:44
|
> -----Original Message-----
> From: dev...@li...=20
> [mailto:dev...@li...] On Behalf=20
> Of OROSZI Bal?zs
> Sent: Monday, August 04, 2003 5:20 PM
> To: dev...@li...
> Subject: [Dev-C++] loop optimization
>=20
>=20
> Hi!
>=20
> Now, I have a question.
> I need to do heavy optimizations in the project I am working=20
> on, and I=20
> am asking you, whether will I gain any speedup by optimizing=20
> loops. I am=20
> interested in the for loop exactly. Let's take this example:
>=20
> for(i=3D0;i<getint();i++){
> /* ... */
> }
>=20
> Would it worth it to take that getint() into an outer=20
> variable, and only=20
> use that in the conditional, like this:
>=20
> int c =3D getint();
> for(i=3D0;i<c;i++){
> /* ... */
> }
You do not specify language (why?) so I assume C.
In C99 if the function can be inlined (and you have used the keyword =
inline)
it will be inlined so you do not get any gain. If it cannot be inlined =
then
by placing it outside the loop you gain some run-time (the time cost of =
the
subsequent funtion calls, which is much if the calls are many).
>=20
> Will this give me any speedup? I am interested in particular, is for=20
> going to call getint() EVERY time in the first case (on top),=20
> or will it=20
> do it only once? I think the second case is better, am I right?
>=20
> Allright, that was my first question, here is the second:
> What is the case, if the conditional is a KNOWN value.=20
> Something, like a=20
> macro. Here is the example:
>=20
> #define GETINT (10*5)
>=20
> for(i=3D0;i<GETINT;i++){
> /* ... */
> }
>=20
> I suppose, this will be optimised by the compiler, and this=20
> can even be=20
> unrolled, am I right?
Well in theory the compiler can be smart without any limits. The only =
worst
case scenario assumption you can make is that the loop will be executed =
50
times (the GETINT is inlined of course).
Ioannis Vranos
=20
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net
|
|
From: Graham D. <g.d...@nt...> - 2003-08-05 18:43:33
|
Run the profiler to find out where the inefficiencies are. In my
experience, any attempt to prejudge optimisation will be wrong. The
inefficiencies are _never_ where you expect.
The two fundamental rules for optimising by hand are:
rule 1: don't do it.
rule 2: don't do it - yet.
OROSZI Balázs wrote:
> Hi!
>
> Now, I have a question.
> I need to do heavy optimizations in the project I am working on, and I
> am asking you, whether will I gain any speedup by optimizing loops. I
> am interested in the for loop exactly. Let's take this example:
>
> for(i=0;i<getint();i++){
> /* ... */
> }
>
> Would it worth it to take that getint() into an outer variable, and
> only use that in the conditional, like this:
>
> int c = getint();
> for(i=0;i<c;i++){
> /* ... */
> }
>
> Will this give me any speedup? I am interested in particular, is for
> going to call getint() EVERY time in the first case (on top), or will
> it do it only once? I think the second case is better, am I right?
>
> Allright, that was my first question, here is the second:
> What is the case, if the conditional is a KNOWN value. Something, like
> a macro. Here is the example:
>
> #define GETINT (10*5)
>
> for(i=0;i<GETINT;i++){
> /* ... */
> }
>
> I suppose, this will be optimised by the compiler, and this can even
> be unrolled, am I right?
>
> Thanks in advance.
> --
> Greetings,
> Balázs
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>
|
|
From: <or...@vp...> - 2003-08-05 19:17:19
|
Graham Douglas wrote: > Run the profiler to find out where the inefficiencies are. In my > experience, any attempt to prejudge optimisation will be wrong. The > inefficiencies are _never_ where you expect. > > The two fundamental rules for optimising by hand are: > > rule 1: don't do it. > rule 2: don't do it - yet. Thanks. Advice taken :) -- Greetings, Balázs |