Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #9810 > unrolled thread

does virtualizing all methods slow C++ down ?

Back to article view | Back to comp.lang.c++

Contents

  does virtualizing all methods slow C++ down ? Lynn McGuire <lmc@winsim.com> - 2011-09-06 11:31 -0500
    Re: does virtualizing all methods slow C++ down ? Christopher <cpisz@austin.rr.com> - 2011-09-06 10:00 -0700
      Re: does virtualizing all methods slow C++ down ? Lynn McGuire <lmc@winsim.com> - 2011-09-06 14:09 -0500
        Re: does virtualizing all methods slow C++ down ? Christopher <cpisz@austin.rr.com> - 2011-09-06 12:35 -0700
          Re: does virtualizing all methods slow C++ down ? "Kevin P. Fleming" <news@kpfleming.us> - 2011-09-06 16:41 -0500
        Re: does virtualizing all methods slow C++ down ? "Balog Pal" <pasa@lib.hu> - 2011-09-11 12:02 +0200
      Re: does virtualizing all methods slow C++ down ? "Thomas J. Gritzan" <phygon_antispam@gmx.de> - 2011-09-07 02:42 +0200
        Re: does virtualizing all methods slow C++ down ? Noah Roberts <roberts.noah@gmail.com> - 2011-09-07 07:39 -0700
          Re: does virtualizing all methods slow C++ down ? Richard Damon <news.x.richarddamon@xoxy.net> - 2011-09-07 11:46 -0400
      Re: does virtualizing all methods slow C++ down ? Nobody <nobody@nowhere.com> - 2011-09-07 01:45 +0100
    Re: does virtualizing all methods slow C++ down ? Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2011-09-06 19:12 +0200
      Re: does virtualizing all methods slow C++ down ? Lynn McGuire <lmc@winsim.com> - 2011-09-06 14:13 -0500
        Re: does virtualizing all methods slow C++ down ? jacob navia <jacob@spamsink.net> - 2011-09-06 21:57 +0200
          Re: does virtualizing all methods slow C++ down ? Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2011-09-06 22:40 +0200
            Re: does virtualizing all methods slow C++ down ? Lynn McGuire <lmc@winsim.com> - 2011-09-06 16:13 -0500
              Re: does virtualizing all methods slow C++ down ? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-09-07 08:01 +0000
                Re: does virtualizing all methods slow C++ down ? Lynn McGuire <lmc@winsim.com> - 2011-09-14 12:08 -0500
                  Re: does virtualizing all methods slow C++ down ? Lynn McGuire <lmc@winsim.com> - 2011-09-14 14:04 -0500
          Re: does virtualizing all methods slow C++ down ? Lynn McGuire <lmc@winsim.com> - 2011-09-06 16:11 -0500
            Re: does virtualizing all methods slow C++ down ? Paavo Helde <myfirstname@osa.pri.ee> - 2011-09-07 11:44 -0500
              Re: does virtualizing all methods slow C++ down ? Joshua Maurice <joshuamaurice@gmail.com> - 2011-09-07 14:11 -0700
                Re: does virtualizing all methods slow C++ down ? Paavo Helde <myfirstname@osa.pri.ee> - 2011-09-08 01:26 -0500
                Re: does virtualizing all methods slow C++ down ? Nobody <nobody@nowhere.com> - 2011-09-08 07:37 +0100
                Re: does virtualizing all methods slow C++ down ? zindorsky <nephi.allred@gmail.com> - 2011-09-09 10:20 -0700
                  Re: does virtualizing all methods slow C++ down ? "Kevin P. Fleming" <news@kpfleming.us> - 2011-09-10 11:48 -0400
                    Re: does virtualizing all methods slow C++ down ? Nobody <nobody@nowhere.com> - 2011-09-10 17:58 +0100
    Re: does virtualizing all methods slow C++ down ? Juha Nieminen <nospam@thanks.invalid> - 2011-09-07 06:19 +0000
    Re: does virtualizing all methods slow C++ down ? Goran <goran.pusic@gmail.com> - 2011-09-06 23:52 -0700
      Re: does virtualizing all methods slow C++ down ? Juha Nieminen <nospam@thanks.invalid> - 2011-09-07 07:57 +0000
        Re: does virtualizing all methods slow C++ down ? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-09-07 10:39 +0000
        Re: does virtualizing all methods slow C++ down ? Goran <goran.pusic@gmail.com> - 2011-09-07 04:30 -0700
          Re: does virtualizing all methods slow C++ down ? Juha Nieminen <nospam@thanks.invalid> - 2011-09-07 13:04 +0000
            Re: does virtualizing all methods slow C++ down ? Goran <goran.pusic@gmail.com> - 2011-09-07 06:18 -0700
    Re: does virtualizing all methods slow C++ down ? ld <laurent.deniau@gmail.com> - 2011-09-08 05:34 -0700

Page 1 of 2  [1] 2  Next page →

#9810 — does virtualizing all methods slow C++ down ?

Does virtualizing all methods slow C++ down ?  We
virtualize all methods as a matter of course since
we use groups of objects all over the place.  To
illustrate this I have included the top portion of
our header files:

class GenGroup : public DataGroup
{
public:
    int transferingDataNow;
public:
       //  constructor
    GenGroup ();
    GenGroup (const GenGroup & rhs);
    GenGroup & operator = (const GenGroup & rhs);
       //  destructor
    virtual ~GenGroup ();
    virtual GenGroup * clone () { return new GenGroup ( * this); }
    virtual void makeUnitsInput (InputCollection * anInpCol);
    virtual void reinitStreamBox (FmFile * FMFile);
    virtual DataDescriptor * descriptor (int aSymbol, int version);
...

Thanks
Lynn

[toc] | [next] | [standalone]

#9813

On Sep 6, 11:31 am, Lynn McGuire <l...@winsim.com> wrote:
> Does virtualizing all methods slow C++ down ?  We
> virtualize all methods as a matter of course since
> we use groups of objects all over the place.  To
> illustrate this I have included the top portion of
> our header files:
>
> class GenGroup : public DataGroup
> {
> public:
>     int transferingDataNow;
> public:
>        //  constructor
>     GenGroup ();
>     GenGroup (const GenGroup & rhs);
>     GenGroup & operator = (const GenGroup & rhs);
>        //  destructor
>     virtual ~GenGroup ();
>     virtual GenGroup * clone () { return new GenGroup ( * this); }
>     virtual void makeUnitsInput (InputCollection * anInpCol);
>     virtual void reinitStreamBox (FmFile * FMFile);
>     virtual DataDescriptor * descriptor (int aSymbol, int version);
> ...
>
> Thanks
> Lynn

If you virtualize one, there is no cost for virtualizing the others.
There is a cost associated with virtualizing one method. See the FAQ.

I wouldn't virtualize every single method in every single class
though. That is just not thoughtful design. When I see a virtual
method, I assume the author INTENDED for the class to be derived from.
Surely, you have a concrete class somewhere.

[toc] | [prev] | [next] | [standalone]

#9819

On 9/6/2011 12:00 PM, Christopher wrote:
> On Sep 6, 11:31 am, Lynn McGuire<l...@winsim.com>  wrote:
>> Does virtualizing all methods slow C++ down ?  We
>> virtualize all methods as a matter of course since
>> we use groups of objects all over the place.  To
>> illustrate this I have included the top portion of
>> our header files:
>>
>> class GenGroup : public DataGroup
>> {
>> public:
>>      int transferingDataNow;
>> public:
>>         //  constructor
>>      GenGroup ();
>>      GenGroup (const GenGroup&  rhs);
>>      GenGroup&  operator = (const GenGroup&  rhs);
>>         //  destructor
>>      virtual ~GenGroup ();
>>      virtual GenGroup * clone () { return new GenGroup ( * this); }
>>      virtual void makeUnitsInput (InputCollection * anInpCol);
>>      virtual void reinitStreamBox (FmFile * FMFile);
>>      virtual DataDescriptor * descriptor (int aSymbol, int version);
>> ...
>>
>> Thanks
>> Lynn
>
> If you virtualize one, there is no cost for virtualizing the others.
> There is a cost associated with virtualizing one method. See the FAQ.
>
> I wouldn't virtualize every single method in every single class
> though. That is just not thoughtful design. When I see a virtual
> method, I assume the author INTENDED for the class to be derived from.
> Surely, you have a concrete class somewhere.

We have so many methods in our 600 classes and 700K lines
of code that we are not sure what needs to be virtual and
does not.  So we do all to keep from missing 1, 2 or 20.

Thanks,
Lynn

[toc] | [prev] | [next] | [standalone]

#9821

On Sep 6, 2:09 pm, Lynn McGuire <l...@winsim.com> wrote:
> On 9/6/2011 12:00 PM, Christopher wrote:
>
>
>
>
>
> > On Sep 6, 11:31 am, Lynn McGuire<l...@winsim.com>  wrote:
> >> Does virtualizing all methods slow C++ down ?  We
> >> virtualize all methods as a matter of course since
> >> we use groups of objects all over the place.  To
> >> illustrate this I have included the top portion of
> >> our header files:
>
> >> class GenGroup : public DataGroup
> >> {
> >> public:
> >>      int transferingDataNow;
> >> public:
> >>         //  constructor
> >>      GenGroup ();
> >>      GenGroup (const GenGroup&  rhs);
> >>      GenGroup&  operator = (const GenGroup&  rhs);
> >>         //  destructor
> >>      virtual ~GenGroup ();
> >>      virtual GenGroup * clone () { return new GenGroup ( * this); }
> >>      virtual void makeUnitsInput (InputCollection * anInpCol);
> >>      virtual void reinitStreamBox (FmFile * FMFile);
> >>      virtual DataDescriptor * descriptor (int aSymbol, int version);
> >> ...
>
> >> Thanks
> >> Lynn
>
> > If you virtualize one, there is no cost for virtualizing the others.
> > There is a cost associated with virtualizing one method. See the FAQ.
>
> > I wouldn't virtualize every single method in every single class
> > though. That is just not thoughtful design. When I see a virtual
> > method, I assume the author INTENDED for the class to be derived from.
> > Surely, you have a concrete class somewhere.
>
> We have so many methods in our 600 classes and 700K lines
> of code that we are not sure what needs to be virtual and
> does not.  So we do all to keep from missing 1, 2 or 20.
>
> Thanks,
> Lynn- Hide quoted text -
>
> - Show quoted text -


Bad design doesn't make up for a bad process.

Surely, you have unit tests for these classes? Surely those tests
would show whether the expected behavior of a method call resolving to
the derived vs the base is occurring?

[toc] | [prev] | [next] | [standalone]

#9835

On 09/06/2011 02:35 PM, Christopher wrote:
> On Sep 6, 2:09 pm, Lynn McGuire<l...@winsim.com>  wrote:
>> On 9/6/2011 12:00 PM, Christopher wrote:
>>
>>
>>
>>
>>
>>> On Sep 6, 11:31 am, Lynn McGuire<l...@winsim.com>    wrote:
>>>> Does virtualizing all methods slow C++ down ?  We
>>>> virtualize all methods as a matter of course since
>>>> we use groups of objects all over the place.  To
>>>> illustrate this I have included the top portion of
>>>> our header files:
>>
>>>> class GenGroup : public DataGroup
>>>> {
>>>> public:
>>>>       int transferingDataNow;
>>>> public:
>>>>          //  constructor
>>>>       GenGroup ();
>>>>       GenGroup (const GenGroup&    rhs);
>>>>       GenGroup&    operator = (const GenGroup&    rhs);
>>>>          //  destructor
>>>>       virtual ~GenGroup ();
>>>>       virtual GenGroup * clone () { return new GenGroup ( * this); }
>>>>       virtual void makeUnitsInput (InputCollection * anInpCol);
>>>>       virtual void reinitStreamBox (FmFile * FMFile);
>>>>       virtual DataDescriptor * descriptor (int aSymbol, int version);
>>>> ...
>>
>>>> Thanks
>>>> Lynn
>>
>>> If you virtualize one, there is no cost for virtualizing the others.
>>> There is a cost associated with virtualizing one method. See the FAQ.
>>
>>> I wouldn't virtualize every single method in every single class
>>> though. That is just not thoughtful design. When I see a virtual
>>> method, I assume the author INTENDED for the class to be derived from.
>>> Surely, you have a concrete class somewhere.
>>
>> We have so many methods in our 600 classes and 700K lines
>> of code that we are not sure what needs to be virtual and
>> does not.  So we do all to keep from missing 1, 2 or 20.
>>
>> Thanks,
>> Lynn- Hide quoted text -
>>
>> - Show quoted text -
>
>
> Bad design doesn't make up for a bad process.
>
> Surely, you have unit tests for these classes? Surely those tests
> would show whether the expected behavior of a method call resolving to
> the derived vs the base is occurring?

... and surely you have a compiler that is able to warn you when a 
derived class overrides a non-virtual member function in one of its base 
classes?

[toc] | [prev] | [next] | [standalone]

#10046

"Lynn McGuire" <lmc@winsim.com> az alábbiakat írta a következo hírüzenetben: 
j45r7m$bod$1@dont-email.me...
>>> class GenGroup : public DataGroup
>>> {
>>> public:
>>>      int transferingDataNow;
>>> public:
>>>         //  constructor
>>>      GenGroup ();
>>>      GenGroup (const GenGroup&  rhs);
>>>      GenGroup&  operator = (const GenGroup&  rhs);
>>>         //  destructor
>>>      virtual ~GenGroup ();
>>>      virtual GenGroup * clone () { return new GenGroup ( * this); }
>>>      virtual void makeUnitsInput (InputCollection * anInpCol);
>>>      virtual void reinitStreamBox (FmFile * FMFile);
>>>      virtual DataDescriptor * descriptor (int aSymbol, int version);

This looks more than awful as C++ code.

>> If you virtualize one, there is no cost for virtualizing the others.
>> There is a cost associated with virtualizing one method. See the FAQ.

Huh? Yes, you gain a VMT after the first virtual and it will not multiply.
But for every call, late binding is extra cost over early binding, so there 
is a definite cost.

>> I wouldn't virtualize every single method in every single class
>> though. That is just not thoughtful design. When I see a virtual
>> method, I assume the author INTENDED for the class to be derived from.
>> Surely, you have a concrete class somewhere.

Indeed. virtual is not a hodgepodge thing. You use a virtual function to 
have base class communicate with a subclass.
When you make something virtual you must document a ton of things, 
especially what is required from the overrider, semantics, restrictions, 
intent to call/not call the base version, etc... and optimally, provide 
cases when overriding is useful and intended.  Without that you have a sure 
way for disaster, and speed will hardly be a factor.

> We have so many methods in our 600 classes and 700K lines
> of code that we are not sure what needs to be virtual and
> does not.  So we do all to keep from missing 1, 2 or 20.

gcc has a fine warning when you declare a function that hides another one in 
a base class rather than overriding a virtual. Just turn it on and forget 
crippling your codebase even further.

C++11 even have attributes to make the detection a language feature.

[toc] | [prev] | [next] | [standalone]

#9858

> On Sep 6, 11:31 am, Lynn McGuire<l...@winsim.com>  wrote:
>> Does virtualizing all methods slow C++ down ?
 >> [...]

At 06.09.2011 19:00, Christopher wrote:
> If you virtualize one, there is no cost for virtualizing the others.
> There is a cost associated with virtualizing one method. See the FAQ.

That's not true.

It is true that the size of an object increases for the first virtual 
function you add, but not for further virtual functions (for usual 
vpointer implementations).
However, _every_ function might be slower when called virtually, because 
the compiler has less potential for optimization (function inlining etc) 
than for non-virtual functions.

-- 
Thomas

[toc] | [prev] | [next] | [standalone]

#9903

On Sep 6, 5:42 pm, "Thomas J. Gritzan" <phygon_antis...@gmx.de> wrote:
> > On Sep 6, 11:31 am, Lynn McGuire<l...@winsim.com>  wrote:
> >> Does virtualizing all methods slow C++ down ?
>
>  >> [...]
>
> At 06.09.2011 19:00, Christopher wrote:
>
> > If you virtualize one, there is no cost for virtualizing the others.
> > There is a cost associated with virtualizing one method. See the FAQ.
>
> That's not true.
>
> It is true that the size of an object increases for the first virtual
> function you add, but not for further virtual functions (for usual
> vpointer implementations).
> However, _every_ function might be slower when called virtually, because
> the compiler has less potential for optimization (function inlining etc)
> than for non-virtual functions.

Not really.  Most cases where inlining applies are still quite
possible when the functions are virtual.

[toc] | [prev] | [next] | [standalone]

#9906

On 9/7/11 10:39 AM, Noah Roberts wrote:
> On Sep 6, 5:42 pm, "Thomas J. Gritzan"<phygon_antis...@gmx.de>  wrote:
>
> Not really.  Most cases where inlining applies are still quite
> possible when the functions are virtual.

Inlining of virtual functions can only occur if the static type of the 
object is known (which in my experience tends to be rare for this type 
of object) or the virtual function has been declared "final", but for a 
function that really never needed to have been declared virtual, the 
final would have been added to the first deceleration of being declared 
virtual, which implies that it is known that it doesn't need to be 
virtual in the first place.

[toc] | [prev] | [next] | [standalone]

#9859

On Tue, 06 Sep 2011 10:00:56 -0700, Christopher wrote:

> If you virtualize one, there is no cost for virtualizing the others.
> There is a cost associated with virtualizing one method. See the FAQ.

That only deals with the memory cost. There is also a potential speed cost
for every virtual method call.

[toc] | [prev] | [next] | [standalone]

#9814

Lynn McGuire <lmc@winsim.com> writes:

> Does virtualizing all methods slow C++ down ?  We
> virtualize all methods as a matter of course since
> we use groups of objects all over the place.

Not sure I understand what you mean, but yes, virtualizing all
(non-really-virtual) methods will slow things down, in cases where the
compiler cannot statically decide the class where the method is defined.
In the worst case:

- all calls through a reference or pointer will be indirect calls
- all other calls will be direct calls.

The branch predictor may help here, but you still pay some price. In
your example:

>    virtual GenGroup * clone () { return new GenGroup ( * this); }

the compiler would normally (probably) inline any call to this method in
the non-virtual case. With virtual, all calls to this method through a
ref/pointer will be translated into an indirect call.

(I know, cloning usually requires dynamic binding, I used this example
because it was the only method potentially inlinable.)

C++11 provides the "final" qualifier, which may help here. Whether it is
taken into account depends on your compiler.

-- Alain.

[toc] | [prev] | [next] | [standalone]

#9820

On 9/6/2011 12:12 PM, Alain Ketterlin wrote:
> Lynn McGuire<lmc@winsim.com>  writes:
>
>> Does virtualizing all methods slow C++ down ?  We
>> virtualize all methods as a matter of course since
>> we use groups of objects all over the place.
>
> Not sure I understand what you mean, but yes, virtualizing all
> (non-really-virtual) methods will slow things down, in cases where the
> compiler cannot statically decide the class where the method is defined.
> In the worst case:
>
> - all calls through a reference or pointer will be indirect calls
> - all other calls will be direct calls.
>
> The branch predictor may help here, but you still pay some price. In
> your example:
>
>>     virtual GenGroup * clone () { return new GenGroup ( * this); }
>
> the compiler would normally (probably) inline any call to this method in
> the non-virtual case. With virtual, all calls to this method through a
> ref/pointer will be translated into an indirect call.
>
> (I know, cloning usually requires dynamic binding, I used this example
> because it was the only method potentially inlinable.)
>
> C++11 provides the "final" qualifier, which may help here. Whether it is
> taken into account depends on your compiler.
>
> -- Alain.

Thanks, I had not thought about the direct calls just
directly binding to the proper method.  I'll bet that
there are few direct calls in our code though as we
have many children classes.

ObjPtr -> DataGroup -> GenGroup

ObjPtr -> DataGroup -> NodeGroup -> StreamGroup

are a couple of example lineages.

Lynn

[toc] | [prev] | [next] | [standalone]

#9824

Le 06/09/11 21:13, Lynn McGuire a écrit :
> Thanks, I had not thought about the direct calls just
> directly binding to the proper method. I'll bet that
> there are few direct calls in our code though as we
> have many children classes.
>
> ObjPtr -> DataGroup -> GenGroup
>
> ObjPtr -> DataGroup -> NodeGroup -> StreamGroup
>
> are a couple of example lineages.
>
> Lynn

This is completely ridiculous. An indirect call vs a direct call
will cost you some pipeline turbulence and the cache may be flushed, 
really not a big deal.

Have you MEASURED the slowdown? Is it significant in relationship
to OTHER improvements in your code?

Have you profiled your code to KNOW where it is spending 90% of the
time?

Before you answer THOSE questions, worrying about direc/indirect
calls is WASTED time and effort.

[toc] | [prev] | [next] | [standalone]

#9828

jacob navia <jacob@spamsink.net> writes:

> Le 06/09/11 21:13, Lynn McGuire a écrit :
>> Thanks, I had not thought about the direct calls just
>> directly binding to the proper method. I'll bet that
>> there are few direct calls in our code though as we
>> have many children classes.
>>
>> ObjPtr -> DataGroup -> GenGroup
>>
>> ObjPtr -> DataGroup -> NodeGroup -> StreamGroup
>>
>> are a couple of example lineages.
>>
>> Lynn
>
> This is completely ridiculous. An indirect call vs a direct call
> will cost you some pipeline turbulence and the cache may be flushed,
> really not a big deal.

Depends on the code. With lots of small methods (a la Java, with
getters/setters all over the place), it may be significant, mainly
because of the impossibility to inline. Take any program, compile it
with inlining disabled: the difference may be significant.

> Have you MEASURED the slowdown? Is it significant in relationship
> to OTHER improvements in your code?

Hard to measure. You need to change tens/hundreds of classes...

> Have you profiled your code to KNOW where it is spending 90% of the
> time?

In the case I mention above (many small functions), the overhead would
be spread over a large part of the code. Profiling becomes less useful.

> Before you answer THOSE questions, worrying about direc/indirect
> calls is WASTED time and effort.

I've just done this on a piece code that was evaluating an expression
tree on each vertex of a 4D grid, with an insane number of
floating-point ops. Incredible speedup (~120). Granted, the original was
over-engineered, and this may be a corner case.

Regarding Lynn's case, I would say you're right: he may be better off
keeping his current design safe rather than trying to save a few cycles.

-- Alain.

[toc] | [prev] | [next] | [standalone]

#9833

On 9/6/2011 3:40 PM, Alain Ketterlin wrote:
> jacob navia<jacob@spamsink.net>  writes:
>
>> Le 06/09/11 21:13, Lynn McGuire a écrit :
>>> Thanks, I had not thought about the direct calls just
>>> directly binding to the proper method. I'll bet that
>>> there are few direct calls in our code though as we
>>> have many children classes.
>>>
>>> ObjPtr ->  DataGroup ->  GenGroup
>>>
>>> ObjPtr ->  DataGroup ->  NodeGroup ->  StreamGroup
>>>
>>> are a couple of example lineages.
>>>
>>> Lynn
>>
>> This is completely ridiculous. An indirect call vs a direct call
>> will cost you some pipeline turbulence and the cache may be flushed,
>> really not a big deal.
>
> Depends on the code. With lots of small methods (a la Java, with
> getters/setters all over the place), it may be significant, mainly
> because of the impossibility to inline. Take any program, compile it
> with inlining disabled: the difference may be significant.
>
>> Have you MEASURED the slowdown? Is it significant in relationship
>> to OTHER improvements in your code?
>
> Hard to measure. You need to change tens/hundreds of classes...
>
>> Have you profiled your code to KNOW where it is spending 90% of the
>> time?
>
> In the case I mention above (many small functions), the overhead would
> be spread over a large part of the code. Profiling becomes less useful.
>
>> Before you answer THOSE questions, worrying about direc/indirect
>> calls is WASTED time and effort.
>
> I've just done this on a piece code that was evaluating an expression
> tree on each vertex of a 4D grid, with an insane number of
> floating-point ops. Incredible speedup (~120). Granted, the original was
> over-engineered, and this may be a corner case.
>
> Regarding Lynn's case, I would say you're right: he may be better off
> keeping his current design safe rather than trying to save a few cycles.
>
> -- Alain.

You are more than correct, I was just wondering.  In fact, we
saved millions of cycles by porting our code from Smalltalk
to C++.  We had to do it anyway, our Smalltalk variant was
Win16 (don't even go there !) without a Win32 port.  I would
not be surprised if we got a 100X speedup by converting to
C++ and Win32.  Our current design is solid and will not be
changed - we have many other dragons to slay.

Thanks,
Lynn

[toc] | [prev] | [next] | [standalone]

#9876

On Tue, 2011-09-06, Lynn McGuire wrote:
...
> You are more than correct, I was just wondering.  In fact, we
> saved millions of cycles by porting our code from Smalltalk
> to C++.

That explains a lot about that "virtual everywhere" design. Go look in
"The C++ Programming Language"; Stroustrup has a few things to say
about using C++ as if it was Smalltalk.

> Our current design is solid and will not be
> changed - we have many other dragons to slay.

It may not be highest priority, but I still think there's something
seriously wrong with having the code this way -- especially if you
have design rules to forbid normal C++ in new or rewritten code.

My guess (which is only a guess) is that the worst penalty is that it
discourages the use of small classes, wrappers and helper functions
which would make the code more readable. Inlining makes such things
cost-free, but if you don't have inlining you probably think twice
before doing such simplifications (at least I do).

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#10102

On 9/7/2011 3:01 AM, Jorgen Grahn wrote:
> On Tue, 2011-09-06, Lynn McGuire wrote:
> ...
>> You are more than correct, I was just wondering.  In fact, we
>> saved millions of cycles by porting our code from Smalltalk
>> to C++.
>
> That explains a lot about that "virtual everywhere" design. Go look in
> "The C++ Programming Language"; Stroustrup has a few things to say
> about using C++ as if it was Smalltalk.
>
>> Our current design is solid and will not be
>> changed - we have many other dragons to slay.
>
> It may not be highest priority, but I still think there's something
> seriously wrong with having the code this way -- especially if you
> have design rules to forbid normal C++ in new or rewritten code.
>
> My guess (which is only a guess) is that the worst penalty is that it
> discourages the use of small classes, wrappers and helper functions
> which would make the code more readable. Inlining makes such things
> cost-free, but if you don't have inlining you probably think twice
> before doing such simplifications (at least I do).
>
> /Jorgen

Well, we have over 600 classes in our software which dates
back to 1988 or so.

BTW, the reason that we use virtual all over the place is
that we use vectors of base class pointers.  Having the
virtual command is just safer rather than chasing down each
method (and they are MANY) to see if they are over-ridden
by one of the descendent classes.

Thanks for the comments !

Lynn

[toc] | [prev] | [next] | [standalone]

#10106

On 9/14/2011 12:08 PM, Lynn McGuire wrote:
> On 9/7/2011 3:01 AM, Jorgen Grahn wrote:
>> On Tue, 2011-09-06, Lynn McGuire wrote:
>> ...
>>> You are more than correct, I was just wondering. In fact, we
>>> saved millions of cycles by porting our code from Smalltalk
>>> to C++.
>>
>> That explains a lot about that "virtual everywhere" design. Go look in
>> "The C++ Programming Language"; Stroustrup has a few things to say
>> about using C++ as if it was Smalltalk.
>>
>>> Our current design is solid and will not be
>>> changed - we have many other dragons to slay.
>>
>> It may not be highest priority, but I still think there's something
>> seriously wrong with having the code this way -- especially if you
>> have design rules to forbid normal C++ in new or rewritten code.
>>
>> My guess (which is only a guess) is that the worst penalty is that it
>> discourages the use of small classes, wrappers and helper functions
>> which would make the code more readable. Inlining makes such things
>> cost-free, but if you don't have inlining you probably think twice
>> before doing such simplifications (at least I do).
>>
>> /Jorgen
>
> Well, we have over 600 classes in our software which dates
> back to 1988 or so.
>
> BTW, the reason that we use virtual all over the place is
> that we use vectors of base class pointers. Having the
> virtual command is just safer rather than chasing down each
> method (and they are MANY) to see if they are over-ridden
> by one of the descendent classes.
>
> Thanks for the comments !
>
> Lynn

And I failed to complete my thought about inlining, sorry.

We have over 600 classes in our software.  We have many,
many, many helper methods which I have no idea if they
inline or not.  Our Win32 exe is 9,568,256 bytes which is
a little monster.  Total of about 450,000 lines of C++ code
of which 1/3 was converted to C++ from C by changing the
source code file extension.  At this point I really don't
care if code inlines but I would like it to.

Thanks,
Lynn

[toc] | [prev] | [next] | [standalone]

#9832

On 9/6/2011 2:57 PM, jacob navia wrote:
> Le 06/09/11 21:13, Lynn McGuire a écrit :
>> Thanks, I had not thought about the direct calls just
>> directly binding to the proper method. I'll bet that
>> there are few direct calls in our code though as we
>> have many children classes.
>>
>> ObjPtr -> DataGroup -> GenGroup
>>
>> ObjPtr -> DataGroup -> NodeGroup -> StreamGroup
>>
>> are a couple of example lineages.
>>
>> Lynn
>
> This is completely ridiculous. An indirect call vs a direct call
> will cost you some pipeline turbulence and the cache may be flushed, really not a big deal.
>
> Have you MEASURED the slowdown? Is it significant in relationship
> to OTHER improvements in your code?
>
> Have you profiled your code to KNOW where it is spending 90% of the
> time?
>
> Before you answer THOSE questions, worrying about direc/indirect
> calls is WASTED time and effort.

I am not planning on changing our design, it works very well
and gets an amazing amount of work done in the amount of
code written.  After reading the "Generally, are the programs
written by C++ slower than written by C 10% ?" thread, I was
just wondering about the major difference between C and C++
in our code.  In the long and short runs, I would say that
the overhead is more than worth the automatic object method
lookups.  More than !

Thanks,
Lynn

[toc] | [prev] | [next] | [standalone]

#9908

Lynn McGuire <lmc@winsim.com> wrote in news:j462c0$vt9$1@dont-email.me:
> 
> I am not planning on changing our design, it works very well
> and gets an amazing amount of work done in the amount of
> code written.  After reading the "Generally, are the programs
> written by C++ slower than written by C 10% ?" thread, I was
> just wondering about the major difference between C and C++
> in our code.  In the long and short runs, I would say that
> the overhead is more than worth the automatic object method
> lookups.  More than !

If you think that the code is slower than needed, then you should profile 
it and see if there are clear bottlenecks. If these are related to 
virtuals, like calling a virtual function zillion times in a tight loop, 
then you can think about how to cure that specific bottleneck (for example, 
some compilers provide extensions to convert a virtual function pointer 
into a non-virtual one which can then be used inside the loop, providing 
better optimization possibilities). And if the bottlenecks are not related 
to virtuals, then I guess you can pretty much ignore any anticipated 
overhead of virtual calls, unless your app is very performance-critical.

cheers
Paavo

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web