 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
tomgee
Guest
|
 Posted: Sat Dec 16, 2006 6:31 am Post subject: speed performance: reference vs. pointer |
 |
|
While looking up Bjarne's "The C++ Programming Language", I found this
sentence:
"The obvious implementation of a reference is as a (constant) pointer
that is dereferenced each
time it is used. It doesn't do much harm thinking about references
that way, as long as one remembers that a reference isn't an object
that can be manipulated the way a pointer is"
If I understand it correctly, to reference an object, the compiler
first generate a pointer to it and delete it on each occurrence of
usage. Does it mean that a raw pointer could potentially be faster
than a reference?
Can anybody please explain a real life implementation of a reference?
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
 |
Pierre Asselin
Guest
|
| Posted: Sat Dec 16, 2006 10:10 am Post subject: Re: speed performance: reference vs. pointer |
|
|
tomgee <RockOnEdge (AT) gmail (DOT) com> wrote:
| Quote: | While looking up Bjarne's "The C++ Programming Language", I found this
sentence:
"The obvious implementation of a reference is as a (constant) pointer
that is dereferenced each
time it is used.
If I understand it correctly, to reference an object, the compiler
first generate a pointer to it and delete it on each occurrence of
usage.
|
That's not how I understood the passage. I read it as saying that
int &ri= i;
could be implemented as
int * const _hidden_pointer= &i;
#define ri (*_hidden_pointer)
--
pa at panix dot com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
peter koch larsen
Guest
|
| Posted: Sun Dec 17, 2006 12:19 am Post subject: Re: speed performance: reference vs. pointer |
|
|
tomgee skrev:
| Quote: | While looking up Bjarne's "The C++ Programming Language", I found this
sentence:
"The obvious implementation of a reference is as a (constant) pointer
that is dereferenced each
time it is used. It doesn't do much harm thinking about references
that way, as long as one remembers that a reference isn't an object
that can be manipulated the way a pointer is"
If I understand it correctly, to reference an object, the compiler
first generate a pointer to it
|
Well - it might generate a pointer to it, but it might also just "note"
that the reference is an alias:
void example(double& d)
{
d = 2*d + 1;
}
would probably be implemented as if the code was:
void example(double* d)
{
*d = 2* *d + 1;
}
(keeping the "valuelike access pattern).
But code such as:
void f()
{
double d = 2,0;
double& rd = d;
rd = 2*rd + 1;
}
would probable transform into something like:
void f()
{
double d = 2,0;
d = 2*d + 1;
}
| Quote: | and delete it on each occurrence of
usage.
|
No deletion takes place - ever.
| Quote: | Does it mean that a raw pointer could potentially be faster
than a reference?
No. It is the other way around. A reference will in practice always be |
as fast or faster than a pointer.
/Peter
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Xeranic
Guest
|
| Posted: Mon Dec 18, 2006 11:09 pm Post subject: Re: speed performance: reference vs. pointer |
|
|
"tomgee $B<LF;!'(B
"
| Quote: | While looking up Bjarne's "The C++ Programming Language", I found this
sentence:
"The obvious implementation of a reference is as a (constant) pointer
that is dereferenced each
time it is used. It doesn't do much harm thinking about references
that way, as long as one remembers that a reference isn't an object
that can be manipulated the way a pointer is"
If I understand it correctly, to reference an object, the compiler
first generate a pointer to it and delete it on each occurrence of
usage. Does it mean that a raw pointer could potentially be faster
than a reference?
Can anybody please explain a real life implementation of a reference?
|
I don't agree with you. When compile the c++ code, the reference just
be replace by const pointer. It's identity!
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Wed Dec 20, 2006 12:02 am Post subject: Re: speed performance: reference vs. pointer |
|
|
peter koch larsen wrote:
| Quote: | tomgee skrev:
While looking up Bjarne's "The C++ Programming Language", I found this
sentence:
"The obvious implementation of a reference is as a (constant) pointer
that is dereferenced each
time it is used. It doesn't do much harm thinking about references
that way, as long as one remembers that a reference isn't an object
that can be manipulated the way a pointer is"
If I understand it correctly, to reference an object, the compiler
first generate a pointer to it
Well - it might generate a pointer to it,
|
Even when it does use a pointer, the reference version could be
faster, because the compiler knows that it won't change. In
general, the more information the compiler has to work with, the
better it can optimize, and a reference provides more
information than a pointer.
--
James Kanze (GABI Software) email:james.kanze (AT) gmail (DOT) com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Xeranic
Guest
|
| Posted: Wed Dec 20, 2006 8:35 am Post subject: Re: speed performance: reference vs. pointer |
|
|
On Dec 20, 2:02 am, "James Kanze" <james.ka...@gmail.com> wrote:
| Quote: | peter koch larsen wrote:
tomgee skrev:
While looking up Bjarne's "The C++ Programming Language", I found this
sentence:
"The obvious implementation of a reference is as a (constant) pointer
that is dereferenced each
time it is used. It doesn't do much harm thinking about references
that way, as long as one remembers that a reference isn't an object
that can be manipulated the way a pointer is"
If I understand it correctly, to reference an object, the compiler
first generate a pointer to it
Well - it might generate a pointer to it,Even when it does use a
pointer, the reference version could be
faster, because the compiler knows that it won't change. In
general, the more information the compiler has to work with, the
better it can optimize, and a reference provides more
information than a pointer.
--
James Kanze (GABI Software) email:james.ka...@gmail.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, France, +33 (0)1 30 23 00 34
|
The reference's matcher is const pointer, not just pointer. The
compiler also know that won't change. So what kind of optimize compiler
can do on reference but not const pointer. A reference provides no more
information than a const pointer.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Guest
|
| Posted: Wed Dec 20, 2006 7:43 pm Post subject: Re: speed performance: reference vs. pointer |
|
|
Xeranic schreef:
| Quote: | On Dec 20, 2:02 am, "James Kanze" <james.ka...@gmail.com> wrote:
peter koch larsen wrote:
tomgee skrev:
While looking up Bjarne's "The C++ Programming Language", I found
this
sentence:
"The obvious implementation of a reference is as a (constant)
pointer
that is dereferenced each
time it is used. It doesn't do much harm thinking about references
that way, as long as one remembers that a reference isn't an object
that can be manipulated the way a pointer is"
If I understand it correctly, to reference an object, the compiler
first generate a pointer to it
Well - it might generate a pointer to it, Even when it does use a
pointer, the reference version could be
faster, because the compiler knows that it won't change. In
general, the more information the compiler has to work with, the
better it can optimize, and a reference provides more
information than a pointer.
--
James Kanze (GABI Software) email:james.ka...@gmail.com
The reference's matcher is const pointer, not just pointer. The
compiler also know that won't change. So what kind of optimize compiler
can do on reference but not const pointer. A reference provides no more
information than a const pointer.
|
That's not always true (const_cast<T*>).
Another reason compilers can optimize references is because references
cannot be null references. Pointers can be null pointers. And as James
correctly explained, that helps optimizers. Good optimizers can do
null-pointer tracking, though, and for bad optimizers it doesn't matter
anyway, so it's average optimizers that benefit most.
HTH,
Michiel Salters
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Wed Dec 20, 2006 11:08 pm Post subject: Re: speed performance: reference vs. pointer |
|
|
Xeranic wrote:
| Quote: | On Dec 20, 2:02 am, "James Kanze" <james.ka...@gmail.com> wrote:
peter koch larsen wrote:
tomgee skrev:
While looking up Bjarne's "The C++ Programming Language", I found this
sentence:
"The obvious implementation of a reference is as a (constant) pointer
that is dereferenced each
time it is used. It doesn't do much harm thinking about references
that way, as long as one remembers that a reference isn't an object
that can be manipulated the way a pointer is"
If I understand it correctly, to reference an object, the compiler
first generate a pointer to it
Well - it might generate a pointer to it,Even when it does use a
pointer, the reference version could be
faster, because the compiler knows that it won't change. In
general, the more information the compiler has to work with, the
better it can optimize, and a reference provides more
information than a pointer.
The reference's matcher is const pointer, not just pointer. The
compiler also know that won't change. So what kind of optimize compiler
can do on reference but not const pointer. A reference provides no more
information than a const pointer.
|
True. (Or almost---the compiler also knows that the reference
cannot be null, whereas even a const pointer could be null.)
But in practice, I think you'll find that people tend not to
declare pointers const.
--
James Kanze (GABI Software) email:james.kanze (AT) gmail (DOT) com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Wed Dec 20, 2006 11:09 pm Post subject: Re: speed performance: reference vs. pointer |
|
|
Michiel.Salters (AT) tomtom (DOT) com wrote:
| Quote: | Xeranic schreef:
On Dec 20, 2:02 am, "James Kanze" <james.ka...@gmail.com> wrote:
peter koch larsen wrote:
tomgee skrev:
While looking up Bjarne's "The C++ Programming Language", I found this
sentence:
"The obvious implementation of a reference is as a (constant) pointer
that is dereferenced each
time it is used. It doesn't do much harm thinking about references
that way, as long as one remembers that a reference isn't an object
that can be manipulated the way a pointer is"
If I understand it correctly, to reference an object, the compiler
first generate a pointer to it
Well - it might generate a pointer to it, Even when it does use a
pointer, the reference version could be
faster, because the compiler knows that it won't change. In
general, the more information the compiler has to work with, the
better it can optimize, and a reference provides more
information than a pointer.
The reference's matcher is const pointer, not just pointer. The
compiler also know that won't change. So what kind of optimize compiler
can do on reference but not const pointer. A reference provides no more
information than a const pointer.
That's not always true (const_cast<T*>).
|
Trying to modify a const object through a non-const lvalue
expression is undefined behavior. If the pointer (and not what
it is pointing to) is defined const, the compiler is free to
assume that it's value doesn't change.
| Quote: | Another reason compilers can optimize references is because references
cannot be null references. Pointers can be null pointers. And as James
correctly explained, that helps optimizers. Good optimizers can do
null-pointer tracking, though, and for bad optimizers it doesn't matter
anyway, so it's average optimizers that benefit most.
|
That's almost always the case. If the optimizer is turned off,
nothing should help it, and there are very few optimizing
possibilities that cannot be found by a sufficiently good
optimizer, doing full inter-module analysis.
Of course, in some cases, the necessary algorithms are O(N^2)
over the size of the program, which means that the compile times
for a 1 MLOC application could become quite long. And for some
reason, most people do not consider compile times which are
measured in centuries acceptable, regardless of how optimized
the results are. But for something like avoiding unnecessary
checks for null, the compiler could probably find 90% of them in
a reasonable time. And of course, good optimizers use feedback
from the profiler, and don't really do any deep analysis unless
the code is in a critical path.
--
James Kanze (GABI Software) email:james.kanze (AT) gmail (DOT) com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Gennaro Prota
Guest
|
| Posted: Thu Dec 21, 2006 7:38 am Post subject: Re: speed performance: reference vs. pointer |
|
|
On 19 Dec 2006 13:02:28 -0500, James Kanze wrote:
| Quote: | peter koch larsen wrote:
tomgee skrev:
If I understand it correctly, to reference an object, the compiler
first generate a pointer to it
Well - it might generate a pointer to it,
Even when it does use a pointer, the reference version could be
faster, because the compiler knows that it won't change. In
general, the more information the compiler has to work with, the
better it can optimize
|
Can or could. Unfortunately real compilers may surprise you on this. A
recent case I came upon with gcc and my SHA class templates was
something along the lines of:
const int sz( 8 );
template< typename ... >
void f( byte_type( &a )[ sz ] )
{
...
return f_impl( a );
}
template< typename ...>
void f_impl( byte_type( & a )[ sz ] )
{
...
}
It is hard to believe but changing f_impl's parameter to type
byte_type * had a tremendous performance impact on the generated code.
And while I'm generally quite happy with gcc this is the sort of
things that should never happen; I can understand that the compiler is
to some extent a black-box but I don't want my code to become suddenly
half as fast as before --think for instance of the opposite change--
just because I slightly touched/improved it somewhere. And because of
these not so infrequent facts I'm unwillingly convincing myself that
benchmarks should be part of the regression tests.
--
Gennaro Prota. C++ developer. For hire.
(to mail me, remove any 'u' from the address)
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Thu Dec 21, 2006 11:52 pm Post subject: Re: speed performance: reference vs. pointer |
|
|
Gennaro Prota wrote:
| Quote: | On 19 Dec 2006 13:02:28 -0500, James Kanze wrote:
|
[...]
| Quote: | Even when it does use a pointer, the reference version could be
faster, because the compiler knows that it won't change. In
general, the more information the compiler has to work with, the
better it can optimize
Can or could. Unfortunately real compilers may surprise you on this.
|
It's gotten to the point where almost nothing a real compiler
does will surprise me anymore. (Except, maybe, output readable
error messages. That would surprise me.)
| Quote: | A
recent case I came upon with gcc and my SHA class templates was
something along the lines of:
const int sz( 8 );
template< typename ...
void f( byte_type( &a )[ sz ] )
{
...
return f_impl( a );
}
template< typename ...
void f_impl( byte_type( & a )[ sz ] )
{
...
}
It is hard to believe but changing f_impl's parameter to type
byte_type * had a tremendous performance impact on the generated code.
|
Interesting. I would have expected as a first approximation
that the implementation treat it exactly as if you'd passed a
byte_type*, once the template parameters were deduced.
According to the standard, it could add bounds checking (since
the information is present, which it isn't with a pointer), but
somehow, I'd be rather surprised if this were the case.
Did you look at the generated code, to see what the difference
was.
| Quote: | And while I'm generally quite happy with gcc this is the sort of
things that should never happen; I can understand that the compiler is
to some extent a black-box but I don't want my code to become suddenly
half as fast as before --think for instance of the opposite change--
just because I slightly touched/improved it somewhere.
|
And yet, it's unavoidable in certain cases. Imagine an
optimization that is based on the fact that sz is a multiple of
the size of a machine word. Change to a pointer, and the
compiler cannot do it. And I can construct cases (I'm not
saying that they occur in real code) where such optimizations
could makes a significant difference.
| Quote: | And because of
these not so infrequent facts I'm unwillingly convincing myself that
benchmarks should be part of the regression tests.
|
A program has to be "fast enough". And regression tests should
verify that. Even if, in practice, it's rarely a problem. A
modification might slow the program down 10%, but in the
meantime, the machines it's running on have speeded up 50%.
--
James Kanze (GABI Software) email:james.kanze (AT) gmail (DOT) com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Gennaro Prota
Guest
|
| Posted: Sat Jan 06, 2007 3:21 am Post subject: Re: speed performance: reference vs. pointer |
|
|
On 21 Dec 2006 12:52:08 -0500, James Kanze wrote:
| Quote: | Gennaro Prota wrote:
On 19 Dec 2006 13:02:28 -0500, James Kanze wrote:
[...]
Even when it does use a pointer, the reference version could be
faster, because the compiler knows that it won't change. In
general, the more information the compiler has to work with, the
better it can optimize
Can or could. Unfortunately real compilers may surprise you on this.
It's gotten to the point where almost nothing a real compiler
does will surprise me anymore. (Except, maybe, output readable
error messages. That would surprise me.)
|
Well, template-related rebuses apart, EDG frontends rock. For
templates I don't know what can possibly be done... it looks like many
people are happy with STLFilt, but I don't have experience with it
(well, I enjoy rebuses anyway, so my subconscius could have refrained
me from giving it a try  ).
| Quote: | A recent case I came upon with gcc and my SHA class templates was
something along the lines of:
const int sz( 8 );
template< typename ...
void f( byte_type( &a )[ sz ] )
{
...
return f_impl( a );
}
template< typename ...
void f_impl( byte_type( & a )[ sz ] )
{
...
}
It is hard to believe but changing f_impl's parameter to type
byte_type * had a tremendous performance impact on the generated code.
Interesting. I would have expected as a first approximation
that the implementation treat it exactly as if you'd passed a
byte_type*, once the template parameters were deduced.
According to the standard, it could add bounds checking (since
the information is present, which it isn't with a pointer), but
somehow, I'd be rather surprised if this were the case.
Did you look at the generated code, to see what the difference
was.
|
No, I didn't, as I was in the middle of other changes and just
discovered the fact "by chance". The overall structure of the code
however hasn't substantially changed since then, so I could try
reproducing the issue after the release.
| Quote: | [...]
And because of
these not so infrequent facts I'm unwillingly convincing myself that
benchmarks should be part of the regression tests.
A program has to be "fast enough". And regression tests should
verify that. Even if, in practice, it's rarely a problem. A
modification might slow the program down 10%, but in the
meantime, the machines it's running on have speeded up 50%.
|
Yes, that's one of the reasons why in effect I'm reluctant. And
differently from regression tests, performance tests would require you
to store the speed results somewhere, for every supported platform, in
order to compare them with the new ones. I don't know what a solid
solution could be. Of course, I'd just like to detect sudden
substantial performance losses, that could otherwise get unnoticed.
___
\|||/ Gennaro Prota - For hire
(o o) https://sourceforge.net/projects/breeze/
--ooO-(_)-Ooo----- (to mail: name _ surname / yaho ! com)
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
