On 15 Dec 1998 21:33:12 GMT, James.Kanze@dresdner-bank.com wrote:

>I believe this to be so; any indirect function call foils branch
>prediction.

Not necessarily. Branch predictors can easily use patterns
(such as location of branch instruction -- target of branches learned)
to improve predictions. The more C++ applications become widespread,
the more weight will chip designers put into improving their
predictors in those directions.

---------------------------------------------
Ziv Caspi
zivca@netvision.net.il


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <752pj2$mn4@news3.euro.net>,
  "Martijn Lievaart" <nobody@orion.nl> wrote:

> Also, I heard that indirect function calls are slow on some architectures.
> If this is true then the cost of making something virtual that doesn't have
> to be can be even higher.

I believe this to be so; any indirect function call foils branch
prediction.

On the other hand, modern compilers use the output of the profiler in
the optimization phase.  If the calls at a given point are all to
different functions, there is not much it can do, but any other way of
programming the same functionality would probably have similar
overhead.  If the calls are all, or mostly, to the same function, the
compiler might generate an if, and use a direct call (or even inline)
for the most frequent case.

--
James Kanze                                           GABI Software, S   rl
Conseils en informatique orient    objet  --
                          --  Beratung in industrieller Datenverarbeitung
mailto: kanze@gabi-soft.fr          mailto: James.Kanze@dresdner-bank.com

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <752pj2$mn4@news3.euro.net>,
  "Martijn Lievaart" <nobody@orion.nl> wrote:
>
> AllanW@my-dejanews.com wrote in message <74p1ec$mkj$1@nnrp1.dejanews.com>...
> >When you call a virtual function, the compiler cannot know the
> >exact address of the function until run-time. So virtual functions
> >are slower because the address must be looked up before the
> >function is called.
> >
> >Quite a long time ago, Dr. Stroustroup and others published one
> >method to keep the overhead from virtual functions very slight.
> >On many computers the overhead is as little as one memory fetch.
> >As far as I know, the technique he suggested is used in all C++
> >compilers everywhere, with minor variations.
>
> I would say two fetches. One to get the vtable pointer from the object and
> one to get the address of the virtual function.

Yes, two fetches. That's what I meant to say. Oops.

> Also, I heard that indirect function calls are slow on some architectures.
> If this is true then the cost of making something virtual that doesn't have
> to be can be even higher.

This is true on so-called "pipeline" machines, in which the
computer may begin executing instruction N+1 or even N+2 while
instruction N is still finishing. On these computers, an
indirect jump must either make assumptions about which
instruction will execute next (and be prepared to undo them if
they turn out NOT to be next after all), or it must simply
wait until the final address has been determined.

But many of these computers are likely to take a hit on *all*
non-linear execution, including calling a function at a known
address. On these machines the cost of a virtual function call
still isn't all *that* much higher than any other function call.
If the function does any non-trivial work, then the overhead as
a percentage drops to near 0.

I repeat my earlier stand: Like other tools, virtual functions
should be used wherever they are appropriate, and nowhere else.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote in message <74p1ec$mkj$1@nnrp1.dejanews.com>...
>
>In article <366CCD9A.1A0499D3@haje.kaist.ac.kr>,
>  Ahn Ki-yung <kyagrd@haje5.kaist.ac.kr> wrote:
>>
>> In Korean lunar computer magazine Micro Software 1998.8
>> section writing about Java,
>> it says that "We avoid using the virtual funtion in C++ which is a
>> characteristic concept of Object Oreinted Progaming Language
>> because of decrese in performance." And adds that in case of
>> Java "It did not give up the concept for performance like C++
>> but trying to overcome the performance with new technology."
>
>> I want to know why the performace decrease when using
>> vertual funtions.
>
>When you call a virtual function, the compiler cannot know the
>exact address of the function until run-time. So virtual functions
>are slower because the address must be looked up before the
>function is called.
>
>Quite a long time ago, Dr. Stroustroup and others published one
>method to keep the overhead from virtual functions very slight.
>On many computers the overhead is as little as one memory fetch.
>As far as I know, the technique he suggested is used in all C++
>compilers everywhere, with minor variations.
>

I would say two fetches. One to get the vtable pointer from the object and
one to get the address of the virtual function.

A function pointer stored in a struct would only be one fetch, but this is
very space inefficient in general, so the compromise of one fetch extra
versus enormous space savings was chosen for all implementations I'm aware
off.

Also, I heard that indirect function calls are slow on some architectures.
If this is true then the cost of making something virtual that doesn't have
to be can be even higher.

HTH,
Martijn
--
My email address is intentionally invalid, post here if you want to reach
me.




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Martijn Lievaart wrote in message <752pj2$mn4@news3.euro.net>...
>
>AllanW@my-dejanews.com wrote in message <74p1ec$mkj$1@nnrp1.dejanews.com>...
>>
[snip]
>>Quite a long time ago, Dr. Stroustroup and others published one
>>method to keep the overhead from virtual functions very slight.
>>On many computers the overhead is as little as one memory fetch.
>>As far as I know, the technique he suggested is used in all C++
>>compilers everywhere, with minor variations.
>>
>
>I would say two fetches. One to get the vtable pointer from the object and
>one to get the address of the virtual function.

When a non-virtual function is called, the function address is
usually inline in the instruction stream and must be fetched
to be used.  So the the "overhead", or "additional burden"
of the virtual call relative to a plain call is just fetching the
v-table pointer from the object, when counted in fetches.

>A function pointer stored in a struct would only be one fetch, but this is
>very space inefficient in general, so the compromise of one fetch extra
>versus enormous space savings was chosen for all implementations I'm aware
>off.
>
>Also, I heard that indirect function calls are slow on some architectures.

I expect that is true of most modern CPU's.  Instruction
prefetch and speculative execution would have to be
hindered when the instruction addresses appear to
be computed.  I think it is obvious that an inline call
has but one, thoroughly predictable effect on what
instructions will execute, while indirection thru two
pointers is harder to predict, in general.  (I suppose
the v-table case could be optimized, so as to allow
the usual prefetch and speculative execution.)

>If this is true then the cost of making something virtual
>that doesn't have to be can be even higher.

Another case in support of measurement for
performance questions.

--Larry Brasfield
Above opinions may be mine alone.
X-Replace-Address
(Humans may reply at unundered larry_br@sea_net.com )



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <366CCD9A.1A0499D3@haje.kaist.ac.kr>,
  Ahn Ki-yung <kyagrd@haje5.kaist.ac.kr> wrote:
>
> In Korean lunar computer magazine Micro Software 1998.8
> section writing about Java,
> it says that "We avoid using the virtual funtion in C++ which is a
> characteristic concept of Object Oreinted Progaming Language
> because of decrese in performance." And adds that in case of
> Java "It did not give up the concept for performance like C++
> but trying to overcome the performance with new technology."

> I want to know why the performace decrease when using
> vertual funtions.

When you call a virtual function, the compiler cannot know the
exact address of the function until run-time. So virtual functions
are slower because the address must be looked up before the
function is called.

Quite a long time ago, Dr. Stroustroup and others published one
method to keep the overhead from virtual functions very slight.
On many computers the overhead is as little as one memory fetch.
As far as I know, the technique he suggested is used in all C++
compilers everywhere, with minor variations.

So people that suggest that virtual functions are slow are
technically correct, but the difference is very slight.

> What I only know is that it takes time
> when we call the funtion, so if we call the funtion many
> times it will make the process slow.

This is true even without virtual functions. There is always
some time involved in passing arguments and control from one
function to another. On some computers the cost is more severe
than other computers.

> If this is the only
> reason of avoid using virtual funtions how is it possible
> in Java using virtual funtions without the loss of efficiency ?

In Java the RELATIVE cost may be lower, since Java virtual machines
must always be slower than native implementations. In general,
though, I'm sure that Java implementors face many of the same
problems that C++ implementors face. This would include the speed
of function calls, including virtual functions.

> Is the argument right that these problem comes from the
> design of C++ itself ? Isn't it possible to overcome the
> probelms by well designed C++ complier which can maintain
> the OOP concepts ?

It isn't possible to overcome the problem completely. It is
certainly possible to minimize the problem, as I stated
earlier in this message. When virtual functions are used
correctly, they are very efficient. They are at least as fast
as any possible user-designed scheme for changing run-time
behavior of an object -- and sometimes much more efficient.
Since virtual functions are also much more powerful and
extensible than any user-designed scheme, they are the method
of choice.

But like any tool, they can be misused. Some companies
experiment with rules like "always make every function virtual"
and these experiments end up in disasters. Use the tool where
it is appropriate, and nowhere else.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

The authors of that article don't know what they are talking about. The
fastest Java could ever get would be the slowest C++ program ever
written.

In C++, the virtual keyword is optional. It is the mechanism that
provides polymorphism. When you call a virtual function, you do a
runtime lookup to see what type you _really_ have. Then, you call the
appropriate function.

You don't always need virtual functions. If you just need fast,
structured code - don't use it. Plus, you can choose which functions
really need it. Also, in situations where you know what type you are
dealing with, you can you the type qualifier ( Foo::print();) and bypass
the virtual dispatch.

In Java, every function is virtual. Plus, it is interpreted (even JIT
needs some time to compile). Plus, Java uses run-time type information
all the time. In C++, RTTI usage is optional.

John Daniel


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ahn Ki-yung <kyagrd@haje5.kaist.ac.kr> writes:

>In Korean lunar computer magazine Micro Software 1998.8
>section writing about Java,
>it says that "We avoid using the virtual funtion in C++ which is a
>characteristic concept of Object Oreinted Progaming Language
>because of decrese in performance." And adds that in case of
>Java "It did not give up the concept for performance like C++
>but trying to overcome the performance with new technology."

As someone else has pointed out, the statement is complete
nonsense. In Java, (nearly) every function call is a
virtual call. There is no performance decrease, because
(nearly) all function calls are equally slow!

>I want to know why the performace decrease when using
>vertual funtions.

The C++ performance decrease comes from two sources.

1. The function call is indirect, so it takes a few extra machine
cycles compared to a non-virtual call. If the function body does
any real work, the extra cost may be too small to measure.
You really should not worry about the cost of the indirect call
until you can determine by measurement that it affects program
performance.

2. In the presence of a true virtual call, the function cannot
be generated inline. The loss of inlining can be significant.

In some circumstances the compiler can determine that the
virtual call mechanism need not be used, and can call,
or generate inline, the function directly. Example:

class C {
 C();
 virtual void f() { .... }
 virtual void g();
};

C::C() {
 g(); // only C::g could be called, so can be called directly
}

int foo()
{
 C c;
 c.f(); // can be inlined, since not a virtual call
}

---
Steve Clamage, stephen.clamage@sun.com

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ahn Ki-yung wrote:

[snip]

Nonsense.
I think the writer must be biased to Java without enough experiment of C++.
Priciple is simple :
    Indirection gives flexibility, but hurts performance.
    The flexibility of Java comes from indirection.

KiZOo




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In Korean lunar computer magazine Micro Software 1998.8
section writing about Java,
it says that "We avoid using the virtual funtion in C++ which is a
characteristic concept of Object Oreinted Progaming Language
because of decrese in performance." And adds that in case of
Java "It did not give up the concept for performance like C++
but trying to overcome the performance with new technology."

I want to know why the performace decrease when using
vertual funtions. What I only know is that it takes time
when we call the funtion, so if we call the funtion many
times it will make the process slow. If this is the only
reason of avoid using virtual funtions how is it possible
in Java using virtual funtions without the loss of efficiency ?
Is the argument right that these problem comes from the
design of C++ itself ? Isn't it possible to overcome the
probelms by well designed C++ complier which can maintain
the OOP concepts ?



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]