Board index » cppbuilder » Re: vote for a native 64-bit compiler

Re: vote for a native 64-bit compiler


2005-02-23 02:01:29 AM
cppbuilder102
"Hendrik Schober" < XXXX@XXXXX.COM >writes:
Quote
Oscar Fuentes < XXXX@XXXXX.COM >wrote:
>"Hendrik Schober" < XXXX@XXXXX.COM >writes:
>
>>>Bjarne Stroustrup writes in his C++BibleIII, wich I consider to be a good
>>>textbook, that passing small datatypes by value is more efficient then by
>>>reference [...]
>>
>>So does everyone else. That's taken care of by the
>>"unless..." branch in the (quasi) quote below.
>>
>>>Unfortunately he doesn't say what should be considered as a small type.
>>
>>sizeof(T) <= sizeof(T*)
>
>There are architectures where T* is wider than a register (Intel 8086
>FAR for instance). [...]

I am not sure what you're getting at.
If I use a ptr/ref, I'll need 'sizeof(T*)'.
If 'sizeof(T)' actually is bigger than that,
I might just as well pass by copy.
It should also depend on how much "stuff" the copy constructor
actually does. An empty class could still do database transactions,
etc, in its copy constructor.
--
Chris (TeamB);
 
 

Re:Re: vote for a native 64-bit compiler

"Peter Agricola" < XXXX@XXXXX.COM >writes:
Quote
"Oscar Fuentes" wrote:
>To recapitulate: sizeof(T) <= sizeof(T*) seems a good rule for saying
>when is more efficient to use pass-by-ref (supposing T is POD, of
>course).


Not according to mr. Stroustrup. Unless you consider his complex class as
POD.
I didn't mean that small non-POD objects shouldn't be passed by value,
just that the above mentioned "rule" should be re-considered if the
object has an expensive copy-constructor.
--
Oscar
 

Re:Re: vote for a native 64-bit compiler

Chris Uzdavinis (TeamB) < XXXX@XXXXX.COM >wrote:
Quote
[...]
>>>>Unfortunately he doesn't say what should be considered as a small type.

>>>sizeof(T) <= sizeof(T*)
[...]
It should also depend on how much "stuff" the copy constructor
actually does. An empty class could still do database transactions,
etc, in its copy constructor.
That's certainly true. I forgot about this.
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett
 

{smallsort}

Re:Re: vote for a native 64-bit compiler

Stack operations are faster than global memory access as result of
different cache settings. As result passing int by pointer is usually
much slower than passing it by value.
Cheers,
Boian
Hendrik Schober wrote:
Quote
Except that I got it all wrong. I should
have written "If 'sizeof(T)' actually is
/smaller/ than that,..."! :)

Schobi

 

Re:Re: vote for a native 64-bit compiler

Another advantage is that f it does not fit in the register it will
be passed in the stack which allows faster access due to different cache
settings for the stack.
Cheers,
Boian
Oscar Fuentes wrote:
Quote
On some architectures, yes. The big advantage of passing by value is
that the object may fit on a register and then you don't need to
access memory at all inside the called function. BTW, one advantage of
64 bit processors is that it is efficient to pass by value bigger
types, moreover if you have lots of registers.

 

Re:Re: vote for a native 64-bit compiler

Boian Mitov < XXXX@XXXXX.COM >wrote:
Quote
Stack operations are faster than global memory access as result of
different cache settings. As result passing int by pointer is usually
much slower than passing it by value.
That's why my original answer was
sizeof(T) <= sizeof(T*)
(Note the '<=' operator.)
OTOH, very often the objects passed by value
are on the stack, too:
void f()
{
int i = 42;
g(&i);
}
Quote
Boian
[...]
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett
 

Re:Re: vote for a native 64-bit compiler

Alex Bakaev [TeamB] wrote:
Quote
p.s. btw, that variable should've been named 'the_answer', not 'i' <g>

I'm sorry, what was the question???
David Erbas-White
(couldn't help myself...)
 

Re:Re: vote for a native 64-bit compiler

"David Erbas-White" < XXXX@XXXXX.COM >wrote in message
Quote
Alex Bakaev [TeamB] wrote:
>p.s. btw, that variable should've been named 'the_answer', not 'i' <g>
>

I'm sorry, what was the question???
The mice are working on it but there could be
problems (galactic bypasses etc.) At least
the fjords are cool.
 

Re:Re: vote for a native 64-bit compiler

Alex Bakaev [TeamB] < XXXX@XXXXX.COM >wrote:
Quote
Hendrik Schober wrote:
OTOH, very often the objects passed by value
>are on the stack, too:
>
>void f()
>{
>int i = 42;
>g(&i);
>}
>
>
I'm not sure I understand the above. What is passed by value there?
Sorry. I meant to say "per reference".
Quote
.a

p.s. btw, that variable should've been named 'the_answer', not 'i' <g>
:)
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett
 

Re:Re: vote for a native 64-bit compiler

Alisdair Meredith [TeamB] < XXXX@XXXXX.COM >wrote:
Quote
[...]
Alexandrescu has a nice section in Modern C++ Design on using
type-traits to determine the most efficient manner for passing
parameters to function templates - default is const ref, but small
types such as integers and pointers pass by value instead. IIRC, it
was tweaked for platform detection so that small PODs would also pass
by value if that was detected as more efficient.

[...]

The technique was massive overkill for regular functions though,
resulting in some nicely obfuscated code <g>
Interestingly (and against to what I wrote in
February), I have just become desparate
enough to implement (a simplified of) this. :)
I have some meta code that determines function
arguments and builds type lists from it. There
references and 'const' args really got into my
way.
Quote
AlisdairM(TeamB)
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett