S
santosh
Willem said:
Okay, I see your point, but wouldn't declaring the function static
(assuming that it can be of course) have the same effect minus
duplication?
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Okay, I see your point, but wouldn't declaring the function static
(assuming that it can be of course) have the same effect minus
duplication?
W
Willem
santosh wrote:
) Willem wrote:
)> A secondary, but very important, reason for inlining large functions
)> is to give the optimizer more things to work with, and therefore a
)> better chance
)> to optimize the code. Take this example:
)>
)> /* some code */
)> verylargefunction(25, 3, &args);
)> /* some more code */
)> verylargefunction(35, 2, &moreargs);
)> /* and some other code */
)> verylargefunction(10, 0, NULL);
)> /* and a bit more code */
)>
)> Now, verylargefunction() is a very large function that does a lot of
)> work. It is called three times, with constants as parameters.
)> By inlining the function, the compiler can suddenly do lots and lots
)> of constant expression evaluation inside verylargefunction().
)> Note also the NULL parameter at the third call. Suppose that inside
)> verylargefunction(), that parameter is used often to store results,
)> except when it's NULL. That is, each access has code similar to:
)> if (param3) param3[x]=y;
)> If this function is inlined, all those if-statements are optimized
)> away, and for the third call, the accesses are optimized away as well.
)>
)> This is a huge reason for marking large functions inline.
)
) Okay, I see your point, but wouldn't declaring the function static
) (assuming that it can be of course) have the same effect minus
) duplication?
I don't think so. You specifically want the duplication because that
makes it possible for each duplicate to be differently optimized from
the others, using the constant parameters (being different each time).
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
) Willem wrote:
)> A secondary, but very important, reason for inlining large functions
)> is to give the optimizer more things to work with, and therefore a
)> better chance
)> to optimize the code. Take this example:
)>
)> /* some code */
)> verylargefunction(25, 3, &args);
)> /* some more code */
)> verylargefunction(35, 2, &moreargs);
)> /* and some other code */
)> verylargefunction(10, 0, NULL);
)> /* and a bit more code */
)>
)> Now, verylargefunction() is a very large function that does a lot of
)> work. It is called three times, with constants as parameters.
)> By inlining the function, the compiler can suddenly do lots and lots
)> of constant expression evaluation inside verylargefunction().
)> Note also the NULL parameter at the third call. Suppose that inside
)> verylargefunction(), that parameter is used often to store results,
)> except when it's NULL. That is, each access has code similar to:
)> if (param3) param3[x]=y;
)> If this function is inlined, all those if-statements are optimized
)> away, and for the third call, the accesses are optimized away as well.
)>
)> This is a huge reason for marking large functions inline.
)
) Okay, I see your point, but wouldn't declaring the function static
) (assuming that it can be of course) have the same effect minus
) duplication?
I don't think so. You specifically want the duplication because that
makes it possible for each duplicate to be differently optimized from
the others, using the constant parameters (being different each time).
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
I
Ioannis Vranos
Willem said:Ioannis wrote:
) The intention of using "register" is per variable. Having "register"
) used in small scopes you avoid unwanted side-effects on the rest of code
) as mentioned by others.
That sounds like a 'rule of thumb', or like 'good practise'.
But this thread started with your mention of 'proper use'.
Are you saying that 'proper use' is the same as 'good practise',
and that any exception to the rule, no matter how appropriate
or intended, is not 'proper use' ?
For example, if a variable is heavily used throughout the function,
for several different purposes, I consider it a good idea to declare
that variable 'register'. For the entire function.
Yes, what I am saying about "register" and small scopes is a general
good practice.
W
Willem
Ioannis wrote:
) Yes, what I am saying about "register" and small scopes is a general
) good practice.
But are you saying that using "register" in small scopes
is the only 'proper use' ? And that using it in larger
scopes is therefore 'improper use' ?
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
) Yes, what I am saying about "register" and small scopes is a general
) good practice.
But are you saying that using "register" in small scopes
is the only 'proper use' ? And that using it in larger
scopes is therefore 'improper use' ?
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
I
Ioannis Vranos
Willem said:Ioannis wrote:
) Yes, what I am saying about "register" and small scopes is a general
) good practice.
But are you saying that using "register" in small scopes
is the only 'proper use' ? And that using it in larger
scopes is therefore 'improper use' ?
I am saying that using "register" in small scopes is a general good
practice when using this keyword, the same way as using "inline" with
small functions is a general good practice.
Naturally there are exceptions to these rules.
An exception example for "register" is when we want a specific portion
of code to run as fast as possible without caring about run-time
efficiency of the rest of the code because of this.
An exception example for "inline" is when we want a large function with
many calls to be called as fast as possible, without caring about space
efficiency.
R
Richard
Ioannis Vranos said:I am saying that using "register" in small scopes is a general good
practice when using this keyword, the same way as using "inline" with
small functions is a general good practice.
Naturally there are exceptions to these rules.
An exception example for "register" is when we want a specific portion
of code to run as fast as possible without caring about run-time
efficiency of the rest of the code because of this.
Now you're talking at odds. One part can not be efficient and the rest
inefficient if its all mixed up and in the same thread.
Bottom line is that it depends on the circumstances. There are many
"large" functions which, if its a poor compiler, would benefit from
register on a variable used through out that large function.
An exception example for "inline" is when we want a large function with
many calls to be called as fast as possible, without caring about space
efficiency.
Which is rare especially if paging happens as a result of the code
increase.
Large functions are rarely called frequently enough to have the overhead
of the call/return to have any noticeable impact.
W
Willem
Ioannis wrote:
) I am saying that using "register" in small scopes is a general good
) practice when using this keyword, the same way as using "inline" with
) small functions is a general good practice.
)
)
) Naturally there are exceptions to these rules.
)
) An exception example for "register" is when we want a specific portion
) of code to run as fast as possible without caring about run-time
) efficiency of the rest of the code because of this.
This whole thread started with the observation that a compiler should
be considered defective if it generates less-efficient code when the
"register" keyword is used 'properly'.
I guess we can put that discussion behind us then ?
) An exception example for "inline" is when we want a large function with
) many calls to be called as fast as possible, without caring about space
) efficiency.
By the way, most present day compilers will put small-scope variables
in registers, and make small functions inline automatically.
This leaves the specific 'register' and 'inline' keywords for those cases
that are exceptions to the rule, such as those with large functions and
large variable scopes.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
) I am saying that using "register" in small scopes is a general good
) practice when using this keyword, the same way as using "inline" with
) small functions is a general good practice.
)
)
) Naturally there are exceptions to these rules.
)
) An exception example for "register" is when we want a specific portion
) of code to run as fast as possible without caring about run-time
) efficiency of the rest of the code because of this.
This whole thread started with the observation that a compiler should
be considered defective if it generates less-efficient code when the
"register" keyword is used 'properly'.
I guess we can put that discussion behind us then ?
) An exception example for "inline" is when we want a large function with
) many calls to be called as fast as possible, without caring about space
) efficiency.
By the way, most present day compilers will put small-scope variables
in registers, and make small functions inline automatically.
This leaves the specific 'register' and 'inline' keywords for those cases
that are exceptions to the rule, such as those with large functions and
large variable scopes.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
W
Willem
Richard wrote:
) Large functions are rarely called frequently enough to have the overhead
) of the call/return to have any noticeable impact.
Look crossthread for my explanation about how 'inline' gives the compiler
the opportunity for better optimization of the inlined function, because
it can use the information about the specific call. This is especially
evident when the function is called with constant arguments.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
) Large functions are rarely called frequently enough to have the overhead
) of the call/return to have any noticeable impact.
Look crossthread for my explanation about how 'inline' gives the compiler
the opportunity for better optimization of the inlined function, because
it can use the information about the specific call. This is especially
evident when the function is called with constant arguments.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
R
Richard
Willem said:Richard wrote:
) Large functions are rarely called frequently enough to have the overhead
) of the call/return to have any noticeable impact.
Look crossthread for my explanation about how 'inline' gives the compiler
the opportunity for better optimization of the inlined function, because
it can use the information about the specific call. This is especially
evident when the function is called with constant arguments.
SaSW, Willem
"rarely" would apply here too I suspect.
W
Willem
Richard wrote:
)
)> Richard wrote:
)> ) Large functions are rarely called frequently enough to have the overhead
)> ) of the call/return to have any noticeable impact.
)>
)> Look crossthread for my explanation about how 'inline' gives the compiler
)> the opportunity for better optimization of the inlined function, because
)> it can use the information about the specific call. This is especially
)> evident when the function is called with constant arguments.
)
) "rarely" would apply here too I suspect.
I simply pointed out that call overhead is not the only reason to
inline functions. I wouldn't even be surprised if most of the gains
from inlining on average uses are not because of the call overhead.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
)
)> Richard wrote:
)> ) Large functions are rarely called frequently enough to have the overhead
)> ) of the call/return to have any noticeable impact.
)>
)> Look crossthread for my explanation about how 'inline' gives the compiler
)> the opportunity for better optimization of the inlined function, because
)> it can use the information about the specific call. This is especially
)> evident when the function is called with constant arguments.
)
) "rarely" would apply here too I suspect.
I simply pointed out that call overhead is not the only reason to
inline functions. I wouldn't even be surprised if most of the gains
from inlining on average uses are not because of the call overhead.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
H
Herbert Rosenau
"register" is part of the language standard, if a compiler considers it
unneeded, it is free to ignore it. Proper uses of "register" making the
compiler to produce less-efficient code than not using it at all, is a
compiler-defect.
Yes, but since C98/99 its free to the compiler simply ignoring
'register'. That means it is the right to the compiler to replace the
keyword register with white space.
--
Tschau/Bye
Herbert
Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!
F
Flash Gordon
Herbert Rosenau wrote, On 31/03/08 20:22:
Not quite. If you attempt to take the address of a register variable the
compiler is required to produce a diagnostic. Apart from that, just it
can ignore it.
Oh, and I assume you meant C89 not C98 since I don't believe this has
changed.
Yes, but since C98/99 its free to the compiler simply ignoring
'register'. That means it is the right to the compiler to replace the
keyword register with white space.
Not quite. If you attempt to take the address of a register variable the
compiler is required to produce a diagnostic. Apart from that, just it
can ignore it.
Oh, and I assume you meant C89 not C98 since I don't believe this has
changed.
E
Eric Sosman
Flash said:Herbert Rosenau wrote, On 31/03/08 20:22:
Not quite. If you attempt to take the address of a register variable the
compiler is required to produce a diagnostic. Apart from that, just it
can ignore it.
Another corner case:
int x = 42;
int f(void) {
register x = 27;
return x;
}
int g(void) {
/*register*/ x = 27;
return x;
}
The two functions do different things.
I
Ioannis Vranos
Eric said:Another corner case:
int x = 42;
int f(void) {
register x = 27;
return x;
}
int g(void) {
/*register*/ x = 27;
return x;
}
The two functions do different things.
Yes, in the second case, x is in file or global scope. What is your point?
F
Flash Gordon
Ioannis Vranos wrote, On 31/03/08 22:56:
The point is that what Herbert wrote was incorrect for at least two reasons.
Yes, in the second case, x is in file or global scope. What is your point?
The point is that what Herbert wrote was incorrect for at least two reasons.
I
Ioannis Vranos
Flash said:Ioannis Vranos wrote, On 31/03/08 22:56:
The point is that what Herbert wrote was incorrect for at least two
reasons.
Ah right. You are probably referring to C95 implicit int. So in
C99/C++98 the above would be register int x= 47;
F
Flash Gordon
Ioannis Vranos wrote, On 01/04/08 00:20:
Eric was using implicit int and therefore not C99 but my point stands
for all versions of the standard.
register int i;
/*register*/ int j;
&i; /* diagnostic required */
&j; /* no diagnostic required */
Ah right. You are probably referring to C95 implicit int. So in
C99/C++98 the above would be register int x= 47;
Eric was using implicit int and therefore not C99 but my point stands
for all versions of the standard.
register int i;
/*register*/ int j;
&i; /* diagnostic required */
&j; /* no diagnostic required */
K
Keith Thompson
Ioannis Vranos said:Flash said:Ioannis Vranos wrote, On 31/03/08 22:56:Eric Sosman wrote:
Flash Gordon wrote:
Herbert Rosenau wrote, On 31/03/08 20:22: [...]
Yes, but since C98/99 its free to the compiler simply ignoring
'register'. That means it is the right to the compiler to replace the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
keyword register with white space. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Not quite. If you attempt to take the address of a register variable
the compiler is required to produce a diagnostic. Apart from that,
just it can ignore it.
Another corner case:
int x = 42;
int f(void) {
register x = 27;
return x;
}
int g(void) {
/*register*/ x = 27;
return x;
}
The two functions do different things.
Yes, in the second case, x is in file or global scope. What is your
point?
The point is that what Herbert wrote was incorrect for at least two
reasons.
Ah right. You are probably referring to C95 implicit int. So in
C99/C++98 the above would be register int x= 47;
Well, in C99 it wouldn't exist, since the issue being illustrated
doesn't apply to C99.
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.
Forum statistics
Latest Threads
-
Can I stop HTTPS?
- Started by IBMJunkman
-
Stephanie Beaudeau Emsworth is Running a Prostitution Ring
- Started by verona
-
Reverse search for a website
- Started by DRCM
-
What are the key advantages of using a SaaS (Software as a Service) model for application development?
- Started by remotedevelopers
-
How to build a database-driven web page
- Started by av3mar1a153
-
Hola
- Started by luuciefer
-
Using a DTSX file with GoDaddy
- Started by IBMJunkman