Boost logo

Boost :

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.


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

Boost list run by bdawes at, gregod at, cpdaniel at, john at