[boost] Re: Smart Pointer Timing Test Results

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2000-01-31 12:27:59

What is sad here is how easily Dave could hack up an allocator that is
way faster than the system defaults.  There is no reason, given what we
know about memory allocation, for the system allocator to be any slower
than what Dave did, but vendors keep on shipping crap.

I've sent a (proprietary, belongs to a former employer) fast allocator
that I wrote to Dave and Gavin to try if they want.  If it measures up
well enough I'll consider boosting it.

I think the bottom line remains, until someone shows otherwise, that
given an adequate allocator there is not very much difference in the
performance of the various implementations of shared smart pointers.

Yes, I know, a nanosecond here, a nanosecond there, and pretty soon
your talking real time ...

----- Original Message ----- 
From: Gavin Collings <gcollings_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, January 31, 2000 9:58 AM
Subject: [boost] Smart Pointer Timing Test Results

> Here are the timing test results.
> 
> Initial refers to the default constructor call which would need to
> allocate reference counts, for example.  Copy op refers to half an
> assignment plus half a copy-cons.  "Fast Shared" refers to Dave's
> version of shared_ptr using a special purpose allocator.
> 
> All times in ns and refer to the overhead over and above the equivalent
> raw pointer operation.
> 
> 
> GCC 2.95.2 (-O3 -DNDEBUG)
> 
>           Linked        Shared         Fast Shared   Shared In    
> Cyclic
> Initial  -180 +/- 150   2750 +/- 140   410 +/- 110    45 +/- 120   420
> +/- 60
> Copy Op   280 +/-  25    260 +/-  20   235 +/-  20   130 +/-  20   313
> +/- 10
> 
> 
> Visual C 6.0 SP 3 ("Release" mode)
> 
>           Linked        Shared         Fast Shared   Shared In    
> Cyclic
> Initial  -330 +/- 120   1860 +/- 140   540 +/- 114  -160 +/- 70    140
> +/- 70
> Copy Op   140 +/-  20     90 +/-  23    55 +/-  19    68 +/- 12    140
> +/- 12
> 
> 
> You'll see that some of the initialisation values are negative.  This
> is due to the difficulty in accurately backing out the overhead -
> different optimisations etc.  The same numbers have been taken away
> from each type of pointer though, so the differences between these
> numbers should be valid - i.e. they can be used to calculate number of
> copy operations trade-offs.
> 
> So for example, in Visual C++ fast_shared_in_ptr becomes more efficient
> than linked_ptr at: -
> 
>         (540 - (-330)) / (140 - 55)  = about 10 copy operations.
> 
> 
> Method (for those interested )
> 
> The test involves iterating a loop which creates raw pointers, which it
> then shares among a varying number (set size) of smart pointers.  The
> same operations are then performed on raw pointers to get an idea of
> unavoidable computation.  The raw pointer figure is subtracted leaving
> (hopefully) just the overhead.  A range of set sizes was used and then
> a curve fitted to get a linear relation with number of initialisations
> and copy-ops.
> 
> The code is now in the doc vault - subdirectory smart_pointers.  All
> the results are there, the program calculates most of the numbers, but
> doesn't fit a line to them.  You can use the spreadsheets to do that (I
> know, Microsoft Proprietary Excel, but you can ignore them too).
> 
> Gavin.