- Boost-users - lists.preview.boost.org

boost::shared_ptr performance
by Matthew Wilson 15 Nov '03

15 Nov '03

[I posted this in boost.devel, but got no response. Presumably that was the wrong group. :)] Hi Boosters I'm just doing some research on reference-counting, and contrasting self-counting types with externally counted types, the latter effected with the rather excellent shared pointer technique. [As a side question, is it true that Nicolai Josuttis was the inventor of the technique?] Naturally, one of the shared pointer's I've used is boost::shared_ptr. The measurements have demonstrated some surprising performance characteristics for shared_ptr in particular, and I want to solicit the opinion of the expert's here before I make any bold claims, as some results are just too surprising for me to trust them. There are five types tested. 1. A self-counting type, using an ancient Synesis (my company) template ref-counting bolt-in class 2. A self-counting type, using a custom-written (for this test) template ref-counting bolt-in class 3. Externally counting, using boost::shared_ptr 4. Externally counting, using a custom-written (for this test) shared pointer type 5. Externally counting, using a custom-written (for this test) shared pointer type, which has a custom allocator for the shared count members There were three scenarios investigated, and the same algorithms were applied to the above five types A: Saving refs vector<smart-ptr> ptrs; loop (100,000 times) { smart-ptr sp1(new Thing); sp1 = sp1; smart-ptr p2; p2 = p1; smart-ptr p3(p1); smart-ptr p4(p3); smart-ptr p5(p4); smart-ptr p6(p5); process_Thing(p6.get()); // A function to do something (actually it just returns the result of a call on Thing) to prevent elision by optimisation ptrs.push_back(p5); } The whole is executed within a single thread, and the program is tested in both single and multithreaded forms. B: Discarding refs This is identical to A ("Saving refs") except that saving them to the vector of ptrs is omitted. Again, this is done in one thread, and single and multi-threaded forms tested C: Multi-threaded sharing 20 smart-pointers are created, containing 20 Thing instances, in the main thread. Then 20 threads, using the following thread-proc, are created, and executed. Two times are recorded for each scenario: the total time, and the sum of the individual thread-times (obtained by the WinSTL threadtimes_counter, based on the Win32 API function GetThreadTimes()) std::vector<ptr_type> ptrs(ITERATIONS / 10); for(size_t i = 0; i < 10; ++i) { for(size_t j = 0; j < ITERATIONS / 10; ++j) { ptrs.push_back(things[i % things.size()]); } } ITERATIONS is 100,000. things is the shared shared_ptr array The purpose of this one is to really exercise the sharing between threads. Results (all results are expressed in terms of the most costly pointer) ============================================= [Note, all were compiled with Intel 7.0 with very aggressive speed optimisations (-O2 -Ox -QaxMKW /Qvc7 -EHsc), and executed in a single session on an otherwise quiescent 512MB 2GHz XP box.] A (single-threaded) -------------------- 1. Synesis self-counter: 65% 2. Custom self-counter: 58% 3. boost::shared_ptr: 100% 4. custom SharedPtr: 53% 5. custom SharedPtr + rc pool): 48% I was not surprised that the crusty old Synesis type was slower than the custom self-counter. As expected, the custom shared-ptr with rc pool was the fastest. I was a little surprised that the Boost shared_ptr was up to twice as slow. However, they're all within 100% of each other, so it's no big result I guess. A (multi-threaded) -------------------- 1. Synesis self-counter: 90% 2. Custom self-counter: 46% 3. boost::shared_ptr: 100% 4. custom SharedPtr: 28% 5. custom SharedPtr + rc pool): 27% This was surprising. I expected the use of thread-safe operations (atomic increments, etc.) to flatten out the curve, but the reverse has happened. Interestingly, the two real-world types (Synesis::RefCounter and boost::shared_ptr) fair less well. Again, not what I expected. B (single-threaded) -------------------- 1. Synesis self-counter: 65% 2. Custom self-counter: 55% 3. boost::shared_ptr: 100% 4. custom SharedPtr: 59% 5. custom SharedPtr + rc pool): 53% This scenario has a lot more reference-increments, and a lot less deallocation of the reference-counted instance. Nonetheless, the results are virtually identical, in relative terms (the actual times taken are about 50% across the board). B (multi-threaded) -------------------- 1. Synesis self-counter: 71% 2. Custom self-counter: 41% 3. boost::shared_ptr: 100% 4. custom SharedPtr: 32% 5. custom SharedPtr + rc pool): 31% Pretty much the same as with B (single-threaded). The results are the same, in relative terms Up to this point, the results are mildly interesting, but nothing earth shattering. C - (Times are total time, and thread times, respectively) 1. Synesis self-counter: 2.9% 39% 2. Custom self-counter: 2.7% 35% 3. boost::shared_ptr: 100% 100% 4. custom SharedPtr: 1.0% 13% 5. custom SharedPtr + rc pool): 1.2% 15% This scenario tells quite a different tail indeed. One thing to note is that because of the degree of reference-sharing between the ptr-storing vectors in the 20 threads, the ref-count-pool becomes a pessimisation as a result of the number of actual smart pointer instances being created exceeding the arbitrary 1024 cached ref-counts available. It's likely that this number would not be exceeded in real-world scenarios, so the pool is probably still worth having. Naturally, the very big question is: what's happening to boost::shared_ptr? In thread times, it performs 2-3 times worse than in single threaded scenarios (irrespective of whether they are built for single or multiple threads). However, in total time, it performs extremely poorly, up to 100 times slower than some of the others! Clearly, there is some serious contention involved. There are three possibilities I have thought of: (i) It performs very poorly in multi-threaded sharing scenarios. If this is the case, can any people more expert in Boost than me proffer an explanation as to precisely the problem, and is any such person motivated to try and address the issue? (ii) The particular sharing scenario is well away from any real-world scenario in which boost::shared_ptr is likely to be used. If this is the case, why do four different implementations, representing two very different reference-counting strategies, all maintain a consistent relative performance? What are the scenarios for which boost::shared_ptr is optimised? (iii) There are environment settings for which boost::shared_ptr will perform much better. If that's so, can someone help me out with suggestions of what defines to make? Why are these settings not the default. I'd be very interested in your thoughts. Many thanks in advance. -- Matthew Wilson STLSoft moderator (http://www.stlsoft.org) Contributing editor, C/C++ Users Journal (www.synesis.com.au/articles.html#columns) "You can tell a Yorkshireman, but you can't tell him much!" -- Uncle Michael ---------------------------------------------------------------------------- --- _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Property map deletion
by David Ohlemacher 14 Nov '03

14 Nov '03

Hi all. Partway through my app's execution, I find that I no longer need the values in a custom property map (edge). The map potentially may be quite large. What is the best way to empty it? Thanks, -d

3 7

Boost and Windows CE - does it?
by Steve Folly 14 Nov '03

14 Nov '03

Hi, I know the real answer is probably to just 'try it', but I thought I'd ask to see if anyone else has tried this. We have an application framework which makes extensive use of boost, particularly shared pointers. Currently, we can build Win32 and Mac Carbon applications. Has anyone successfully built applications utilising boost for Windows CE? In particular, we've just started looking at the eMbedded Visual C++ 4.0 compiler and the Pocket PC 2003 SDK. -- Regards, Steve.

1 0

Re: 'long long' problem on VC++7.1
by Nick Savoiu 14 Nov '03

14 Nov '03

And here's what's missing.... I'm using the /Za switch (Disable Language Extensions). But I'm a bit puzzled. I would have thought that /Za (a more standard compliant mode) would not fail. Nick "Nick Savoiu" <savoiu(a)ics.uci.edu> wrote in message news:... > That would be a solution but 'long long' appears in quite a few places. So, > I think there's something else that I'm missing... > > Nick > > "Jeff Garland" <jeff(a)crystalclearsoftware.com> wrote in message > news:20031111022332.M81509@crystalclearsoftware.com... > > On Mon, 10 Nov 2003 14:14:04 -0800, Nick Savoiu wrote > > > I'm trying to compile some boost code on VC+7.1 but I get: > > > > > > e:\users\savoiu\Projects\boost-1.30.2\boost\concept_check.hpp(183) : > > > error C2632: 'long' followed by 'long' is illegal > > > > > > Do I need any #defines when using Boost with VC++7.1 or should it > > > work right out of the box? > > > > I believe this is an error in the concept_check code. Try changing the > 'long > > long' to boost::int64_t. > > > > Jeff > >

2 5

Compiler error with STLport-4.6
by Peter Westerstrom 14 Nov '03

14 Nov '03

Hello, I get this internal compiler error below when compiling boost-regex (from cvs today 11 nov 2003) using STLport-4.6. The error do not show up when using STLport-4.5.3 though. Any ideas? Problem in STLport-4.6 or boost, that's the question? cl -Ic:\EON\builds\head\Development\ExternalLibraries\include\stlport /nologo /MT /W3 /GX /O2 /GB /GF /Gy /Ic:\EON\builds\head\Development\ExternalLibraries\include\stlport /I..\..\..\ /D_MT /DWIN32 /DNDEBUG /D_MBCS /D_LIB /c -DBOOST_REGEX_STATIC_LINK -D_STLP_USE_STATIC_LIB -D_RTLDLL -Y- -Fo./vc6-stlport/libboost_regex-vc6-mt-sp-1_31/ -Fdvc6-stlport/libboost_regex-vc6-mt-sp-1_31.pdb ../src/c_regex_traits.cpp Command line warning D4002 : ignoring unknown option '-Y-' c_regex_traits.cpp ..\..\..\boost/detail/allocator.hpp(67) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'msc1.cpp', line 1794) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. Peter Westerstrom peterw(a)eonreality.se

3 4

RE: [Boost-users] Building Regex++ lib on Pocket PC using EmbeddedVC++4.0
by Ben Hutchings 14 Nov '03

14 Nov '03

Reuti(a)sdc.canon.co.in <Reuti(a)sdc.canon.co.in> wrote: > Has anyone tried building regex++ lib for PPC using EVC++? > I can build it using VC++6.0 using the .mak files supplied > with it.But I am getting errors and warnings. > Error is regarding the use of typename keyword in lib source > and warning is about C++ Exceptions unwinding capability. > > I replaced C++ try, catch by Win32 __try , __except That isn't going to help you. While the Win32 exceptions will be caught and thrown there will be no unwinding of the stack, i.e. destructors for automatic variables will *not* be called. So the code will not work correctly in case of an exception. The approach I've seen is to call abort() instead of throwing, which is probably not a very good one. > but don't know what to do with template error? > > Can anybody help in this? > Also can it be confirmed that its possible to port it on Win CE? Not with EVC++. I'm afraid it's something of a waste of time to try to compile standard C++ code with it. There has been some work to port GNU C++ to WinCE but it is incomplete and so far as I know only covers SH3 and MIPS whereas the most popular architecture for WinCE now seems to be ARM.

5 5

[BGL] Problem with color maps for undirected_dfs_visit
by Tarjei Knapstad 14 Nov '03

14 Nov '03

I'm trying to implement a DFS visitor and using it with undirected_dfs_visit, but I'm getting a segfault which relates to the edge color map. I've made the following test app for illustration: **************** START CODE **************** #include <vector> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/undirected_dfs.hpp> using namespace boost; struct Types { typedef adjacency_list<vecS, vecS, undirectedS, property<vertex_color_t, default_color_type>, property<edge_color_t, default_color_type, property<edge_index_t, int> > > GraphType; typedef std::vector<default_color_type> ColorVec; typedef color_traits<default_color_type> Color; }; int main() { Types::GraphType g(6); add_edge(0,1,g); add_edge(1,2,g); add_edge(2,3,g); add_edge(2,4,g); add_edge(4,5,g); Types::ColorVec v_colors(num_vertices(g), Types::Color::white()); Types::ColorVec e_colors(num_edges(g), Types::Color::white()); default_dfs_visitor visitor; undirected_depth_first_visit(g, 0, visitor, make_iterator_property_map(&v_colors[0], get(vertex_index, g)), make_iterator_property_map(&e_colors[0], get(edge_index, g))); }; **************** END CODE **************** The code crashes in undirected_dfs.hpp line 73 the first time it's trying to access a color from the edge color map: EColorValue uv_color = get(edge_color, *ei); Valgrind turns up a lot of illegal reads/writes to the edge_color_map as well, so I'm guessing that I've screwed up on the colormap creation. Could anyone point out my error? Also, is this an error that could be caught compile time by adding some sort of concept check? Thanks in advance for any help! Regards, -- Tarjei

2 2

Boost.Thread: inlined constructor in thread_specific_ptr block application start up
by Roland 14 Nov '03

14 Nov '03

Dear Boosters, I am trying to understand how to use the TSS Thread local storage, and came upon a strange behaviour. I do not know if I am doing something wrong here. Maybe someone can help. I am running on Win2K, VC6.0. (GUI Interface programm type) In my main thread I have: struct oops { // inline oops(); // commented out, won't run oops(); // this one starts up ~oops(); private: int i; }; oops::oops() { i = 0; } oops::~oops() { } boost::thread_specific_ptr<oops> value; I am not assigning to value anywhere. Now when I try to start my programm (I tried only the debug version) my GUI never comes up. When I break into with the debugger I can see, that the programm is sitting somewhere in the main message loop (PumpMessage), but never receiving any messages. When not having the inlined version, behaviour is ok. Any help appreciated. Thank you, Roland

1 0

RE: [Boost-users] boost::shared_ptr inside std::list
by Darryl Green 13 Nov '03

13 Nov '03

> -----Original Message----- > From: James Mastro [mailto:jmastro@rochester.rr.com] > Sent: Thursday, 13 November 2003 11:59 AM > To: Boost Users mailing list > Subject: [Boost-users] boost::shared_ptr inside std::list > > > This one has been driving me nuts all day. In a function I have the > following: > > std::list< boost::shared_ptr<MyObject> > * objectList; An uninitialized pointer to a list of shared pointers to MyObject is probably not what you wanted, but its what you defined. I don't think you bug has anything to do with shared pointers... > > > When debugging my code, the debugger (gdb) dies upon entering the > function with this in it. It says "The Debugger has exited > due to signal > 11 (SIGSEGV).The Debugger has exited due to signal 11 > (SIGSEGV)." My dev > tools felt the need to say it twice for some reason. I pulled this out > and put it in a new project all by itself with the same result. > > If I make it not be a pointer, like this: > > std::list< boost::shared_ptr<MyObject> > objectList; > > then there's no problem. Regards Darryl. ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################

2 1

RE: [Boost-users] Re: travelling salesman for BGL ?
by Ben Hutchings 13 Nov '03

13 Nov '03

Dave <better_cs_now(a)yahoo.com> wrote: > You'll be a millionaire (literally!) if you figure out the exact > solution to TSP in an efficient manner! Only if you patent it as a "business method".

1 0