By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,905 Members | 900 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,905 IT Pros & Developers. It's quick & easy.

call by address vs. call by value

P: n/a
Why is "call by address" faster than "call by value"?
Nov 14 '05 #1
Share this Question
Share on Google+
35 Replies


P: n/a
hasho <p7******@ccmail.ncku.edu.tw> scribbled the following:
Why is "call by address" faster than "call by value"?


It's not necessarily. It could be, but then it could be not. The C
standard does not define anything about what is faster than what. It is
strictly a QoI issue only.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Bad things only happen to scoundrels."
- Moominmamma
Nov 14 '05 #2

P: n/a
*Ideally* call by address is faster because call by value makes a new copy
of the argument everytime you call the function.
Call by address does no copies instead pass the address of the variable as
is.

So basically the speed issue comes from the overhead produced by making
copies of the variables.

--
Elias
"hasho" <p7******@ccmail.ncku.edu.tw> wrote in message
news:1a**************************@posting.google.c om...
Why is "call by address" faster than "call by value"?

Nov 14 '05 #3

P: n/a
On 10 Feb 2004 04:35:52 -0800, the right honourable
p7******@ccmail.ncku.edu.tw (hasho) wrote:
Why is "call by address" faster than "call by value"?


think of calling a hughe data structure by value...

And, btw. the two methods are not interchangeable without penalty, as
may be suggested by your question. they are completely different in
nature.

frgr
Erik

Nov 14 '05 #4

P: n/a
lallous wrote:
*Ideally* call by address is faster because call by value makes a new copy
of the argument everytime you call the function.
Call by address does no copies instead pass the address of the variable as
is.
Call by address does at least one copy. The address needs to be copied
last time I checked.

So basically the speed issue comes from the overhead produced by making
copies of the variables.


The speed issue comes from the fact that with an address less might
need to be copied. Consider passing structures for example.

--
Thomas.

Nov 14 '05 #5

P: n/a
j

"hasho" <p7******@ccmail.ncku.edu.tw> wrote in message
news:1a**************************@posting.google.c om...
Why is "call by address" faster than "call by value"?


What do you think ``call-by-address'' is?
Nov 14 '05 #6

P: n/a
Joona I Palaste wrote:
hasho wrote:
Why is "call by address" faster than "call by value"?


It's not necessarily. It could be, but then it could be not. The C
standard does not define anything about what is faster than what.
It is strictly a QoI issue only.


I thought that C defined only call by value, and that call by address
was merely mimicked by passing the value of a pointer to an object.

Perhaps I misunderstood?

Nov 14 '05 #7

P: n/a
Grumble <in*****@kma.eu.org> scribbled the following:
Joona I Palaste wrote:
hasho wrote:
Why is "call by address" faster than "call by value"? It's not necessarily. It could be, but then it could be not. The C
standard does not define anything about what is faster than what.
It is strictly a QoI issue only.

I thought that C defined only call by value, and that call by address
was merely mimicked by passing the value of a pointer to an object. Perhaps I misunderstood?


Well, technically you are right. I understood hasho's "call by address"
to mean "passing address with call by value".

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"I wish someone we knew would die so we could leave them flowers."
- A 6-year-old girl, upon seeing flowers in a cemetery
Nov 14 '05 #8

P: n/a
In article <40********@nntphost.cis.strath.ac.uk> Thomas Stegen CES2000 <ts************@cis.strath.ac.uk> writes:
lallous wrote:
*Ideally* call by address is faster because call by value makes a new copy
of the argument everytime you call the function.
Call by address does no copies instead pass the address of the variable as
is.


Call by address does at least one copy. The address needs to be copied
last time I checked.

So basically the speed issue comes from the overhead produced by making
copies of the variables.


The speed issue comes from the fact that with an address less might
need to be copied. Consider passing structures for example.


On the other hand call by address might mean that more has to be copied.
Consider passing structures by address for example, and you use each
field many times.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Nov 14 '05 #9

P: n/a
"Dik T. Winter" <Di********@cwi.nl> wrote in message
news:Hs********@cwi.nl...
In article <40********@nntphost.cis.strath.ac.uk> Thomas Stegen CES2000 <ts************@cis.strath.ac.uk> writes:
> lallous wrote:
> > *Ideally* call by address is faster because call by value makes a new copy > > of the argument everytime you call the function.
> > Call by address does no copies instead pass the address of the variable as > > is.

>
> Call by address does at least one copy. The address needs to be copied
> last time I checked.
>
> >
> > So basically the speed issue comes from the overhead produced by making > > copies of the variables.
> >

>
> The speed issue comes from the fact that with an address less might
> need to be copied. Consider passing structures for example.


On the other hand call by address might mean that more has to be copied.
Consider passing structures by address for example, and you use each
field many times.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland,

+31205924131 home: bovenover 215, 1025 jn amsterdam, nederland;

http://www.cwi.nl/~dik/

Hello

Dik and Thomas, I didn't understand your point?

When calling by address the only thing that is being copied is the address
of the variable that you're accessing by address.
That applies to structures or any other variable.

Whereas when calling by value, a copy of the structure will be made before.

--
Elias
Nov 14 '05 #10

P: n/a
On Tue, 10 Feb 2004 15:23:18 +0100, Grumble <in*****@kma.eu.org>
wrote:
Joona I Palaste wrote:
hasho wrote:
Why is "call by address" faster than "call by value"?


It's not necessarily. It could be, but then it could be not. The C
standard does not define anything about what is faster than what.
It is strictly a QoI issue only.


I thought that C defined only call by value, and that call by address
was merely mimicked by passing the value of a pointer to an object.

Perhaps I misunderstood?


It is not clear to me that C "defines" call by /anything/, as the only
place I could locate the term "call by value" in the Standard was in
the index, referring to section 6.5.2.2, but the term itself doesn't
even seem to be used in that section.

Colloquially, I usually use the terms "pass by value" and "pass by
name" (or reference, or pointer...although using "reference" can be
problematic in C++) /in close conjunction/ with the object being
passed that way. For example:

int i, j;
foo(i); // pass i by value
bar(&i); // pass i by reference

Perhaps your question is related to the dual nature of the call to
bar; it can be described as "passing i by reference", and also as
"passing a pointer to i by value".
-leor
Leor Zolman
BD Software
le**@bdsoft.com
www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
C++ users: Download BD Software's free STL Error Message
Decryptor at www.bdsoft.com/tools/stlfilt.html
Nov 14 '05 #11

P: n/a
"lallous" <la*****@lgwm.org> wrote:

[ Don't top-post, please. ]
"hasho" <p7******@ccmail.ncku.edu.tw> wrote in message
news:1a**************************@posting.google.c om...
Why is "call by address" faster than "call by value"?

*Ideally* call by address is faster because call by value makes a new copy
of the argument everytime you call the function.
Call by address does no copies instead pass the address of the variable as
is.


That is the theory, based on a very restricted view of a rather
old-fashioned kind of implementation, with no arguments passed in
registers and rather larger objects than pointers. Actual practice
doesn't always agree with this theory.
In fact, in practice, which objects will be faster passed as pointers
and which are faster passed directly depends entirely on the
architecture, the compiler, and possibly even on the generation of the
architecture (i.e., it could differ between a Pentium II and a Pentium
III). The only way to know which is best for you is to measure, and not
to assume that your measurements are correct for others.
Even then, in most cases the difference between pointer and value
passing is likely to be dwarfed by algorithmic choices. If passing a
pointer makes calling the function slightly faster, but actually doing
anything inside the function slower, more complicated, and more error-
prone, only a fool uses the pointer. Ditto vice versa.

Richard
Nov 14 '05 #12

P: n/a
In article <c0*************@ID-161723.news.uni-berlin.de> "lallous" <la*****@lgwm.org> writes:
"Dik T. Winter" <Di********@cwi.nl> wrote in message
news:Hs********@cwi.nl...

....
On the other hand call by address might mean that more has to be copied.
Consider passing structures by address for example, and you use each
field many times.


When calling by address the only thing that is being copied is the address
of the variable that you're accessing by address.
That applies to structures or any other variable.

Whereas when calling by value, a copy of the structure will be made before.


But consider what it takes to pick up the value of a field within a routine
with the two passing modes.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Nov 14 '05 #13

P: n/a
j

"Leor Zolman" <le**@bdsoft.com> wrote in message
news:5g********************************@4ax.com...
On Tue, 10 Feb 2004 15:23:18 +0100, Grumble <in*****@kma.eu.org>
wrote:
Joona I Palaste wrote:
hasho wrote:

Why is "call by address" faster than "call by value"?

It's not necessarily. It could be, but then it could be not. The C
standard does not define anything about what is faster than what.
It is strictly a QoI issue only.
I thought that C defined only call by value, and that call by address
was merely mimicked by passing the value of a pointer to an object.

Perhaps I misunderstood?


It is not clear to me that C "defines" call by /anything/, as the only
place I could locate the term "call by value" in the Standard was in
the index, referring to section 6.5.2.2, but the term itself doesn't
even seem to be used in that section.


The standard defines ``pass by value''
Look up what ``value of the expression'' means
Colloquially, I usually use the terms "pass by value" and "pass by
name" (or reference, or pointer...although using "reference" can be
problematic in C++) /in close conjunction/ with the object being
passed that way. For example:

int i, j;
foo(i); // pass i by value
bar(&i); // pass i by reference

In both cases, a value is passed. That value in-turn
becomes the value of another container.

``pass by reference'' does not exist in C.
Passing by reference is an entirely different
mechanism in which we pass an actual object to
a function. We then are able to perform operations
upon the passed object as though it were local to
said function.

People commonly mix up ``pass by reference''
with ``pass a reference''

We can pass something we can consider to be a reference
and refer to it as ``pass a reference'' but we can't
use ``pass by reference'' -- they don't mean the same thing.
It is also unneeded when arguments to functions can be
described by a single term ``pass by value'' without the need
of added complexity. -- I find that beginners of C are so
horribly confused because of this.

People will also make the claim that we can emulate
``passing by reference'' by passing pointers but
it isn't all that meaningful(and not to mention, added
complexity). The gross effects can be simulated but
the operation not. The same can also be said for
implementing functions with goto and an explicit stack.

To OP:
Don't use ``call-by-address''. It is such a horribly muddled
term.
call-by-address: call a function by an address
call-by-value: call a function by a value

It _describes_ a way how functions are called as
opposed to how arguments are passed to the function
being called.
Perhaps your question is related to the dual nature of the call to
bar; it can be described as "passing i by reference", and also as
"passing a pointer to i by value".
-leor
Leor Zolman
BD Software
le**@bdsoft.com
www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
C++ users: Download BD Software's free STL Error Message
Decryptor at www.bdsoft.com/tools/stlfilt.html

Nov 14 '05 #14

P: n/a
Dik T. Winter wrote:
In article <40********@nntphost.cis.strath.ac.uk> Thomas Stegen CES2000 <ts************@cis.strath.ac.uk> writes:
> The speed issue comes from the fact that with an address less might
> need to be copied. Consider passing structures for example.


On the other hand call by address might mean that more has to be copied.
Consider passing structures by address for example, and you use each
field many times.


You have to explain this further, because on the face of it, it
makes no sense.

Why do you have to copy less if you have a copy as opposed to a
reference (or pointer)? Are you talking about moving things between
registers? Memory locations?

--
Thomas.

Nov 14 '05 #15

P: n/a
On Tue, 10 Feb 2004 17:33:36 +0200, in comp.lang.c , "lallous"
<la*****@lgwm.org> wrote:
"Dik T. Winter" <Di********@cwi.nl> wrote in message
news:Hs********@cwi.nl...
In article <40********@nntphost.cis.strath.ac.uk> Thomas Stegen CES2000 On the other hand call by address might mean that more has to be copied.
Consider passing structures by address for example, and you use each
field many times.
Dik and Thomas, I didn't understand your point?

When calling by address the only thing that is being copied is the address
of the variable that you're accessing by address.
I think Dik's point is that with call by address, you have to jump to that
address to get the data. If that data happened to be out of segment, or in
paged memory, you could get a bad performance hit.

The other point is that most architectures have registers. Passing values
in registers is generally way faster than using pointers.
Whereas when calling by value, a copy of the structure will be made before.


Which is a one-time hit.

So the real answer is "it depends, go test it in your situation".

For what its worth, I've found situations where pass by value, even of huge
structures, was way more performant. No idea why, but OpenVMS on AXP
hardware seemed to perfer that.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #16

P: n/a

"hasho" <p7******@ccmail.ncku.edu.tw> wrote in message

Why is "call by address" faster than "call by value"?

This may be true for structures.

The reason is that passing a structure on the stack requires several copy
operations to copy each member to the stack, whilst passing the address of
the structure requires a single copy of the address to a register. Generally
the first few arguments of a function will be passed in registers, the
remainder, including large structures, on the stack.
Nov 14 '05 #17

P: n/a
hasho wrote:
Why is "call by address" faster than "call by value"?


You probably mean that
"pass by reference" is faster than "pass by value".

In C, "pass by reference" is accomplished
by passing a pointer by value.

Pass by value requires a copy.
If the object is much larger than a pointer,
it is "faster" to pass a pointer than to pass the object
but, of course, referencing the object through a pointer
usually imposes a slight overhead.
They "break over point" depends upon the details
of the machine architecture and the compiler implementation.

Nov 14 '05 #18

P: n/a
Thomas Stegen CES2000 wrote:

(snip)
Call by address does at least one copy. The address needs to be copied
last time I checked.
(snip)
The speed issue comes from the fact that with an address less might
need to be copied. Consider passing structures for example.


For languages with static allocation the argument lists
can be static, in which case no copying needs to be done.

While I suppose a C program could be written with only static
variables, that would be a rare case.

It is most likely machine dependent which is faster.

-- glen
Nov 14 '05 #19

P: n/a
In article <1a**************************@posting.google.com >,
p7******@ccmail.ncku.edu.tw (hasho) wrote:
Why is "call by address" faster than "call by value"?


What is "call by address"? Could you explain?
Nov 14 '05 #20

P: n/a
On Tue, 10 Feb 2004 13:49:46 GMT, the right honourable
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:
"lallous" <la*****@lgwm.org> wrote:

[ Don't top-post, please. ]
"hasho" <p7******@ccmail.ncku.edu.tw> wrote in message
news:1a**************************@posting.google.c om...
> Why is "call by address" faster than "call by value"?

*Ideally* call by address is faster because call by value makes a new copy
of the argument everytime you call the function.
Call by address does no copies instead pass the address of the variable as
is.


That is the theory, based on a very restricted view of a rather
old-fashioned kind of implementation, with no arguments passed in
registers and rather larger objects than pointers. Actual practice
doesn't always agree with this theory.
In fact, in practice, which objects will be faster passed as pointers
and which are faster passed directly depends entirely on the
architecture, the compiler, and possibly even on the generation of the
architecture (i.e., it could differ between a Pentium II and a Pentium
III). The only way to know which is best for you is to measure, and not
to assume that your measurements are correct for others.
Even then, in most cases the difference between pointer and value
passing is likely to be dwarfed by algorithmic choices. If passing a
pointer makes calling the function slightly faster, but actually doing
anything inside the function slower, more complicated, and more error-
prone, only a fool uses the pointer. Ditto vice versa.

Richard


i think one only can explain this speed difference if one looks at the
processor in question and to the assembler code involved.

Which would bring the question/answer off-topic.
frgr
Erik
Nov 14 '05 #21

P: n/a
In article <c0**********@news-rocq.inria.fr>,
Grumble <in*****@kma.eu.org> wrote:
Joona I Palaste wrote:
hasho wrote:
Why is "call by address" faster than "call by value"?


It's not necessarily. It could be, but then it could be not. The C
standard does not define anything about what is faster than what.
It is strictly a QoI issue only.


I thought that C defined only call by value, and that call by address
was merely mimicked by passing the value of a pointer to an object.

Perhaps I misunderstood?


The topic nazis were asleep.

Yes, there is no such thing as "call by address" in C, so the original
question was completely OT.
Nov 14 '05 #22

P: n/a
On 10 Feb 2004 04:35:52 -0800, the right honourable
p7******@ccmail.ncku.edu.tw (hasho) wrote:
Why is "call by address" faster than "call by value"?


Once more:

I suspect , you look upon this matter in a wrong way.

Why is a bolt better than a nail ?

As we say in dutch: you compare apples and pears.

Call by address means, that the parameter passed to a function is a
pointer, or a memory address.
Apparently, your function needs an address. That was your choice when
you wrote the function. Could be the address of a 10 kb string or of
an integer.

Call by value means that the contents of a piece of memory is passed
as a parameter to the function and thereby duplicated for this
purpose.
Could be an integer, a floating point number, a whole 10 kb string.
Again your decision as a programmer.
It's irrelevant, if the one is faster than the other, because both
have a specific function, their own place in the universe.

And then: what if the value is an address ? then both are equally
speedy :-)
Could be that you need to work on the address inside the function...
who knows ?

Or what if the size of an address is the same as the size of the value
the address points to ?

If you need some integer inside a function, you have to decide if you
need to work on the original data, or on/with a copy of it.
If you have to work on a 10kb data structure, inside a 100x loop, you
do not want to pass all 10k into the function.
But maybe you have to...

frgr
Erik
Nov 14 '05 #23

P: n/a
Erik wrote:

(snip regarding call by address vs. call by value)
i think one only can explain this speed difference if one looks at the
processor in question and to the assembler code involved. Which would bring the question/answer off-topic.


You could try comp.arch, where processor dependence is on topic.

-- glen

Nov 14 '05 #24

P: n/a

On Tue, 10 Feb 2004, Leor Zolman wrote:

Colloquially, I usually use the terms "pass by value" and "pass by
name" (or reference, or pointer...although using "reference" can be
problematic in C++) /in close conjunction/ with the object being
passed that way.


While your statement can be read as correct, I'll nitpick over
the implied equivalence of "pass by name" and "pass by reference,"
which are very different things! See Google Groups for a number
of gigantic threads on the subject of what constitutes pass by
value/reference/copy-and-return/name/text/lazy-evaluation, et al.
C, C++, Java, and friends generally have no built-in equivalent
to pass-by-name. [The answer to your unasked question will be found
in Google Groups.]

-Arthur
Nov 14 '05 #25

P: n/a
In article <b9********************************@4ax.com> Mark McIntyre <ma**********@spamcop.net> writes:
....
"Dik T. Winter" <Di********@cwi.nl> wrote in message
news:Hs********@cwi.nl...
On the other hand call by address might mean that more has to be copied.
Consider passing structures by address for example, and you use each
field many times.
When calling by address the only thing that is being copied is the address
of the variable that you're accessing by address.


I think Dik's point is that with call by address, you have to jump to that
address to get the data. If that data happened to be out of segment, or in
paged memory, you could get a bad performance hit.


I think this was the case with early versions of IBM's AIX on the RS6000.
(If I remember right, a pointer consisted of 32 bits, a 16 bit segment
pointer and a 16 bit relative pointer. So to load a value you first
needed to load the segment pointer and next the relative pointer before
you could load the value. For something passed by value, the
relative pointer was constant and the segment pointer was already in a
register. But this is an extreme situation of the one below.)

Another possibility is if you have a processor that has insufficient
registers. To pick up a value from a struct passed by value the
compiler probably knows the address relative to the frame pointer (see,
this becomes highly machine dependent...), but you need only one load
operation to load the value. To get a similar value from a struct
passed by reference, first the address has to be loaded and next
(using that address and the field offset), the field. Two load
operations. If you use a lot of values that may be more expensive
than a single initial copy. I know of one Fortran compiler (where
parameters are passed by reference or by copy-in, copy-out, depending
on the discretion of the compiler), where the compiler sometimes
decided to make (within the routine) a local copy, which was copied
back at the end.
The other point is that most architectures have registers. Passing values
in registers is generally way faster than using pointers.


Indeed. And in that case pass by value is almost certainly faster.
Moreover, if there are enough registers to pass all arguments by
value, and to store all local variables, the compiler may decide to
dispense of setting up a new stack frame, and so the code comes close
to inlined code which is much faster.

Consider the following two implementations of 'max', using standard C
pass by value, or (what I understand here) pass by reference:

int max(int a, int b) { return (a > b ? a : b);}
int max(int *a, int *b) { return (*a > *b ? *a : *b);}

Consider the call "max(p, q)" vs. "max(&p, &q)". Assume a naive
stackbased compiler. And see what the code would do. Consider
every load and every store as a copy operation...
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Nov 14 '05 #26

P: n/a
On Tue, 10 Feb 2004 17:33:36 +0200, "lallous" <la*****@lgwm.org> wrote
in comp.lang.c:
"Dik T. Winter" <Di********@cwi.nl> wrote in message
news:Hs********@cwi.nl...
In article <40********@nntphost.cis.strath.ac.uk> Thomas Stegen CES2000

<ts************@cis.strath.ac.uk> writes:
> lallous wrote:
> > *Ideally* call by address is faster because call by value makes a new copy > > of the argument everytime you call the function.
> > Call by address does no copies instead pass the address of the variable as > > is.
>
> Call by address does at least one copy. The address needs to be copied
> last time I checked.
>
> >
> > So basically the speed issue comes from the overhead produced by making > > copies of the variables.
> >
>
> The speed issue comes from the fact that with an address less might
> need to be copied. Consider passing structures for example.


On the other hand call by address might mean that more has to be copied.
Consider passing structures by address for example, and you use each
field many times.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland,

+31205924131
home: bovenover 215, 1025 jn amsterdam, nederland;

http://www.cwi.nl/~dik/

Hello

Dik and Thomas, I didn't understand your point?

When calling by address the only thing that is being copied is the address
of the variable that you're accessing by address.
That applies to structures or any other variable.

Whereas when calling by value, a copy of the structure will be made before.


Sometimes the pointer is bigger than the object. And sometimes, even
if the object is larger than the data, the way you access the data via
the pointer might create more overhead than accessing a local copy
that was passed by value.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Nov 14 '05 #27

P: n/a
On Tue, 10 Feb 2004 17:23:51 +0000, Thomas Stegen CES2000
<ts************@cis.strath.ac.uk> wrote in comp.lang.c:
Dik T. Winter wrote:
In article <40********@nntphost.cis.strath.ac.uk> Thomas Stegen CES2000 <ts************@cis.strath.ac.uk> writes:
> The speed issue comes from the fact that with an address less might
> need to be copied. Consider passing structures for example.


On the other hand call by address might mean that more has to be copied.
Consider passing structures by address for example, and you use each
field many times.


You have to explain this further, because on the face of it, it
makes no sense.

Why do you have to copy less if you have a copy as opposed to a
reference (or pointer)? Are you talking about moving things between
registers? Memory locations?


No, he's talking about the total number of memory references including
the function call and the body of the function.

Let's assume a more-or-less typical architecture where function
arguments and local variables are accessed by offset from some sort of
frame pointer register in the processor, examples EBP in a Pentium or
R13 in an ARM.

Now consider a situation where there are not enough registers
available to cache the pointer in a register.

For every access to a member of the struct passed by a pointer, the
compiler must generate two instructions and two memory accesses:

load address_register, *(frame_ptr + struct_ptr_offset)
load data_register, *(address_register + member_offset)

On the other hand, if a copy of the structure is passed, it only
requires one instruction and memory access:

load data_register, *(frame_ptr + struct_offset + member_offset)

If you make many references to members of the structure in the called
function, the extra execution time in the called function may greatly
exceed the time required to copy the struct for passing by value.

Of course the called function can define a local object of the struct
type and initialize by copying from the passed pointer. And in some
cases that is the best option. But in other cases this amounts to
putting a band-aid on what should have been pass by value because
someone automatically believed that "passing a pointer is ALWAYS
better than passing by value."

In general it is the sort of micro-optimization that should only be
performed once the program works correctly but too slowly, and a tool
like a profiler has indicates that this a bottle neck.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Nov 14 '05 #28

P: n/a

I think the moral of all of this thread is that there is no
black and white, only various shades of grey.

You have to know what you are doing and why
(and what your implementation is doing and why)
in order to make a reasoned choice.
Most times, it won't matter in the grand scheme
of things. But when you DO need to make this
kind of optimization, you need to understand
the implications of the decision, both on your
current platform and possible future platforms.
A hard and fast rule just doesn't cut it in all
cases.

Pass by value is not ALWAYS the correct choice
and pass by reference is not ALWAYS the correct choice.

The previous posts in this thread have been extremely
enlightening about the tradeoffs. Life, and programming,
is a series of tradeoffs.

--

"It is impossible to make anything foolproof because fools are so
ingenious" - A. Bloch

Nov 14 '05 #29

P: n/a
Jack Klein wrote:
Sometimes the pointer is bigger than the object.
And sometimes, even if the object is larger than the data,
the way you access the data via the pointer
might create more overhead
than accessing a local copy that was passed by value.


What would really be nice is an example (a simple benchmark)
that illustrated this effect for objects of different sizes
and measured the "break-even" size for user defined types (structs).

Nov 14 '05 #30

P: n/a
Jack Klein wrote:
Now consider a situation where there are not enough registers
available to cache the pointer in a register.


This was the case I did not see (Why on earth not ;).

Thanks.

--
Thomas.

Nov 14 '05 #31

P: n/a
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote:
Jack Klein wrote:
Sometimes the pointer is bigger than the object.
And sometimes, even if the object is larger than the data,
the way you access the data via the pointer
might create more overhead
than accessing a local copy that was passed by value.


What would really be nice is an example (a simple benchmark)
that illustrated this effect for objects of different sizes
and measured the "break-even" size for user defined types (structs).


It would, at first glance, indeed look like this would be useful.
However, its actual value would be greatly diminished by the fact that
the measurements would vary greatly depending on platform,
implementation, and probably even compiler options. In short, you could
demonstrate the presence of the effect; but the break-even size pointed
at in the example could be made invalid by simply using -opt:hi instead
of -opt:medium, or by running it on a Z90 Mk. 4 instead of a Z90 Mk. 3.

Richard
Nov 14 '05 #32

P: n/a
On Tue, 10 Feb 2004 19:00:48 -0500 (EST), "Arthur J. O'Dwyer"
<aj*@nospam.andrew.cmu.edu> wrote:

On Tue, 10 Feb 2004, Leor Zolman wrote:

Colloquially, I usually use the terms "pass by value" and "pass by
name" (or reference, or pointer...although using "reference" can be
problematic in C++) /in close conjunction/ with the object being
passed that way.
While your statement can be read as correct, I'll nitpick over
the implied equivalence of "pass by name" and "pass by reference,"
which are very different things! See Google Groups for a number
of gigantic threads on the subject of what constitutes pass by
value/reference/copy-and-return/name/text/lazy-evaluation, et al.
C, C++, Java, and friends generally have no built-in equivalent
to pass-by-name. [The answer to your unasked question will be found
in Google Groups.]


"unasked question..." sounds like some sort of Zen koan ;-)

If you mean my wondering about how "pass by value" is defined in C
(and I first used the term "call by value" inadvertently; I'm only
talking about argument passing), I've been trying to nail that down
from the Standard, and so far I've been unable to locate any use of
"pass by" anything at all. I've also been told, in a private
discussion, that in the context of C the term "call by value" is
meaningless (this time I do mean "call"), yet ironically there's an
index entry for it in the Standard (it is the only result I get from
searching for "call by" using Acrobat Reader 6's find feature), but I
honestly have not been able to reason out exactly which paragraph of
section 6.5.2.2 it is referring to!

The conclusion I'm drawing from this so far, and this situation is
similar to the one I ran into in an attempt to pin down the precise
meaning of the standalone word "prototype" in the /C++/ Standard (my
conclusion there was that folks are free to use it to mean just about
anything they want, because the term is not specifically defined, and
only /used/ within the phrase "function prototype scope" borrowed from
the C Standard), is that it would not be unreasonable to interpret any
colloquial use of "pass by name", "pass by reference" and "pass by
address" /in the context of C/ to be effectively synonymous. Of
course, one has to consider the source, and the context, but that's
precisely what I try to do when answering a question. I'm on a
learning curve, here...
-leor


-Arthur


Leor Zolman
BD Software
le**@bdsoft.com
www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
C++ users: Download BD Software's free STL Error Message
Decryptor at www.bdsoft.com/tools/stlfilt.html
Nov 14 '05 #33

P: n/a
Leor Zolman <le**@bdsoft.com> wrote:
is that it would not be unreasonable to interpret any
colloquial use of "pass by name", "pass by reference" and "pass by
address" /in the context of C/ to be effectively synonymous.


Almost. In colloquial use, I would consider "pass by address" and "pass
by reference" to be synonymous with "pass a pointer to", with the
proviso that "pass by reference" is ambiguous if C++ gets involved,
which it sometimes does even though it shouldn't.
"Pass by name", however, is something else entirely, and something we
would do well to keep far away from. Here there be dragons. Basically,
"pass by name" is similar, yet dissimilar, to what C does with macros,
with all the strengths those have, and all its dangers as well.

Richard
Nov 14 '05 #34

P: n/a
In article <40*****************@news.individual.net> rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
....
"Pass by name", however, is something else entirely, and something we
would do well to keep far away from. Here there be dragons. Basically,
"pass by name" is similar, yet dissimilar, to what C does with macros,
with all the strengths those have, and all its dangers as well.


I have used it much to my advantage, but not in C of course.
(Jensen's device of course.) The difference with macro's is
of course that macro's are completely compile-time, call-by-name
is not.

(And then there is of course that article in Datamation where the
language Babbage was explained. It had call-by-telephone for
long-distance parameters.)
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Nov 14 '05 #35

P: n/a
Richard Bos wrote:
E. Robert Tisdale wrote:
Jack Klein wrote:
Sometimes the pointer is bigger than the object.
And sometimes, even if the object is larger than the data,
the way you access the data via the pointer
might create more overhead
than accessing a local copy that was passed by value.


What would really be nice is an example (a simple benchmark)
that illustrated this effect for objects of different sizes
and measured the "break-even" size for user defined types (structs).


It would, at first glance, indeed look like this would be useful.
However, its actual value would be greatly diminished by the fact that
the measurements would vary greatly depending on platform,
implementation, and probably even compiler options.
In short, you could demonstrate the presence of the effect;
but the break-even size pointed at in the example
could be made invalid by simply using -opt:hi instead of -opt:medium,
or by running it on a Z90 Mk. 4 instead of a Z90 Mk. 3.


It sure would be nice to have an example that we could use
to confirm or refute all of this conjecture. :-)

Nov 14 '05 #36

This discussion thread is closed

Replies have been disabled for this discussion.