Re: [boost] [statechart] Problems if I make dtorS virtual?

From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-08-24 16:19:22

Hi Dick

BRIDGES Dick wrote:
> When compiling the examples (statechart library downloaded from sf 18
> Aug),
> I get the following warnings:

[snip warnings]

> I changed ~simple_State() and ~state_base() to virtual and the
> warnings disappeared.  However, ~state_base() contains the following
> annotation:
>
> // This destructor is not virtual for performance reasons. The library
> // ensures that a state object is never deleted through a state_base
> // pointer but only through a pointer to the most-derived type.
> ~state_base() {}
>
> As a quick, not-definitive check, I built PingPong* with both the
> virtual
> and non-virtual dtorS using gcc 3.4.2 on an old i386-redhat-linux
> machine.

I would expect the PingPong examples to deliver the least-dependable
information regarding virtual vs. non-virtual dtors. This is due to the
fact that a lot of stuff is going on besides the destruction of states.
I think BitMachine would make for a better testing platform...

> The results appear to be the reverse of what I would expect, but I
> checked
> to verify that I have the correct result/config correspendence.
>
> ..................non-virtual.....virtual
> PingPongSingle....  4.08     .....  3.71
> PingPongMulti1....  6.01997  .....  5.85999
> PingPongMulti2.... 19.53     ..... 19.55

Hmmm, here's what I get on a 3.2GHz Intel Pentium 4 Windows XP machine
(all numbers in microseconds non-virtual / virtual):

*** MSVC7.1 ***

PingPongSingle: 1.06 / 1.07
PingPongMulti1: 5.41 / 5.43
PingPongMulti2: 12.34 / 12.26

BitMachineCustom3: 0.18 / 0.19

*** GCC 3.4.2 (MinGW) ***

PingPongSingle:  1.27 / 1.27
PingPongMulti1:  6.03 / 6.11
PingPongMulti2:  13.20 / 13.27

BitMachineCustom3: 0.32 / 0.30

*** Intel 9.0 ***

PingPongSingle: 1.14 / 1.14
PingPongMulti1: 5.38 / 5.43
PingPongMulti2: 12.27 / 12.35

BitMachineCustom3: 0.16 / 0.16

I.e. no significant difference non-virtual vs. virtual. Two things come
to mind:
1. At the point where states are destructed (see simple_state.hpp, line
983) the compiler might know that the type of the pointer matches the
runtime type of the referenced object and therefore call the virtual
destructor non-virtually. However, I'm not sure whether such compiler
magic is implemented in any of the tested platforms nor do I have a clue
whether that's possible at all (it does sound pretty impossible)
2. There could be little difference on modern processors anyway (as you
have mentioned)

> Reminds me of the old joke:  "I see fine.  I just don't understand
> what
> I'm looking at."  Two questions:  1) will making the dtorS virtual
> lead
> to adverse consequences I simply haven't encountered yet;

Given the numbers above I don't see any problems whatsoever. Not on the
tested processors, that is. I can't say whether the picture is the same
for processors used in the embedded world.

> and 2) can
> someone help me understand what I did wrong in setting up this test?

Difficult to say. Could you build with bjam and repeat the test?

> <extra_credit ot=true my_understanding=faulty>

:-), my understanding is non-existent in this area...

> With a well-developed pipelined architecture and a reasonably rich set
> of addressing operations, shouldn't there be little or no difference
> between direct and indirect access times - given that the bookeeping
> normally associated with virtual classes has already been paid for?
> </extra_credit>

I think my numbers make some limited sense. I don't see how the virtual
dtor version could actually be faster as your numbers suggest.

Regards,

-- 
Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header.