"Philippe A. Bouchard" <[EMAIL PROTECTED]> writes:
> "Peter Dimov" <[EMAIL PROTECTED]> wrote in message
> 000901c2c7dc$e76195e0$1d00a8c0@pdimov2">news:000901c2c7dc$e76195e0$1d00a8c0@pdimov2...
>> From: "Peter Dimov" <[EMAIL PROTECTED]>
>> >
>> > One easy way to estimate the impact of an optimized allocator is to
>> #define
>> > BOOST_SP_USE_STD_ALLOCATOR, to make shared_ptr use std::allocator. On
> SGI
>> > derived STLs, std::allocator is usually faster than plain new.
>>
>> I tried to do that myself but benchmark.cpp doesn't compile for me,
> there's
>> probably no timespec on Windows.
>
> I have defined BOOST_SP_USE_STD_ALLOCATOR in benchmark.cpp (gcc 2.95):
>
> Resources required by list< shifted_ptr<T> >(4000):
> Arena 0:
> system bytes = 226820
> in use bytes = 226052
> Total (incl. mmap):
> system bytes = 226820
> in use bytes = 226052
> max mmap regions = 0
> max mmap bytes = 0
> list shifted_ptr<T> took 0.0002951000 seconds to construct.
> list shifted_ptr<T> took 7.1966276647 seconds to reconstruct 2000
> times.
> list shifted_ptr<T> took 5.0495961000 seconds to copy 2000 times.
> list shifted_ptr<T> took 4.0016951000 seconds to sort 4000 times.
> list shifted_ptr<T> took 0.1382300647 seconds to swap 500 times.
> list shifted_ptr<T> took 0.0003241000 seconds to destroy.
>
> Resources required by list< shared_ptr<T> >(4000):
> Arena 0:
> system bytes = 325124
> in use bytes = 321988
> Total (incl. mmap):
> system bytes = 325124
> in use bytes = 321988
> max mmap regions = 0
> max mmap bytes = 0
> list shared_ptr<T> took 0.0004259000 seconds to construct.
> list shared_ptr<T> took 14.0157271000 seconds to reconstruct 2000 times.
> list shared_ptr<T> took 5.0331178000 seconds to copy 2000 times.
> list shared_ptr<T> took 4.0376376000 seconds to sort 4000 times.
> list shared_ptr<T> took 0.1449102647 seconds to swap 500 times.
> list shared_ptr<T> took 0.0004831000 seconds to destroy.
Would you indulge me and try the benchmark again with the enclosed
shared_count patch applied and #undef BOOST_SP_USE_STD_ALLOCATOR? I
don't really know what's going on under the covers in the SGI
allocator; this is basically just the same hack I threw at the problem
years ago.
My patch doesn't pretend to work for a threaded implementation, so
only the no-threads test applies.
*** shared_count.hpp.~1.31.~ Sun Jan 19 10:14:15 2003
--- shared_count.hpp Wed Jan 29 17:28:11 2003
***************
*** 37,45 ****
--- 37,104 ----
# pragma warn -8027 // Functions containing try are not expanded inline
#endif
+ # include <deque>
+ # include <boost/type_traits/type_with_alignment.hpp>
+ # include <boost/type_traits/alignment_of.hpp>
+
namespace boost
{
+ namespace aux_
+ {
+ // # include <iostream>
+
+ template <unsigned sz, unsigned align>
+ union freeblock
+ {
+ typename boost::type_with_alignment<align>::type aligner;
+ char bytes[sz];
+ freeblock *next;
+ };
+
+ template <unsigned sz, unsigned align>
+ struct allocator_impl
+ {
+ typedef freeblock<sz,align> block;
+
+ static std::deque<block> store;
+ static block* free;
+
+ static inline void* alloc()
+ {
+ block* x = free;
+ if (x)
+ {
+ free = x->next;
+ return x;
+ }
+ else
+ {
+ store.resize(store.size() + 1);
+ return &store.back();
+ }
+ }
+
+ static inline void dealloc(void* p_)
+ {
+ block* p = static_cast<block*>(p_);
+ p->next = free;
+ free = p;
+ }
+ };
+
+
+ template <unsigned sz, unsigned align>
+ std::deque<freeblock<sz,align> > allocator_impl<sz,align>::store;
+
+ template <unsigned sz, unsigned align>
+ freeblock<sz,align>* allocator_impl<sz,align>::free = 0;
+
+ template <class T>
+ struct quick_allocator : allocator_impl<sizeof(T), boost::alignment_of<T>::value>
+ {
+ };
+ }
// Debug hooks
#if defined(BOOST_ENABLE_SP_DEBUG_HOOKS)
***************
*** 272,277 ****
--- 331,346 ----
void operator delete(void * p)
{
std::allocator<this_type>().deallocate(static_cast<this_type *>(p), 1);
+ }
+ #else
+ void * operator new(std::size_t)
+ {
+ return aux_::quick_allocator<this_type>::alloc();
+ }
+
+ void operator delete(void * p)
+ {
+ aux_::quick_allocator<this_type>::dealloc(p);
}
#endif
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
