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.