- Boost - lists.boost.org

[Countertree + Suballocator] New Version
by Francisco José Tapia 03 May '12

03 May '12

Hi this message is to announce the new version of the [countertree + suballocator] library. You can find the zip file with the code and the documentation in https://docs.google.com/file/d/0B9lWJ1Nhb_RhRXVHSS14aGxUZjJjWFdRVC0xZ2czZw/… or if you want a quick look , you can see in my web page http://fjtapia.webs.com/works/countertree/index.html *COUNTERTREE * This library is an implementation of a binary red-black counter tree. This tree have an additional counter in each leaf. This permit the access to the elements by the position, like in a vector. It is a random access container with random access iterators . With this tree we have vectors (cntree::vector_tree) with identical interface than std::vector. The vector_tree have the same speed inserting and deleting in any position (all the operations are O(log N)).It is slower than std:vector inserting and deleting at end, but much faster for to insert and delete in any other position. With ordered information, we have in the cntree namespace the classes set, multiset, map and multimap, with identical interface than the STL classes, with the plus of access to the elements by position, like in a vector. The iterators are random access , and you can subtract two iterators in a O(log N) time for to know the number of nodes between them (even with the end( ) and rend( ) iterators) For to show the utility of this, imagine a large unordered file with the information about the employees of a big company. You have indexes implemented with multimaps, with pairs [value, position], and use the upper_bound and lower_bound functions. You need to select the employees in a range of age and weight. With the boost:multimap you can know the number of elements of the selection. In the weight query we found 100 elements and in the age query 10000 elements. To travel the elements of the weight query asking for the age, is faster than the opposite. *SUBALLOCATOR * A very hard test for the allocators are the data structures which need a very high number (several millions) of elements of the same size, like the STL list, set, multiset, map or multimap. When the number of elements grow, many allocators begin to have speed problems. The solution proposed for this problem are the custom allocators. These allocators are very fast, but many of them present additional problems related with the memory consumption. And they don't work well when they must manage many types of data. When the allocators receive the request from the program, they request memory to the Operating System, and the memory consumed by the program grows up. When the program return to the allocators the request, many allocators have problems for to return the memory freed to the Operating System (The std::allocator of GCC 4.6 don't return well the memory, and the std::allocator of Visual C++, return, but it is slower than the GCC allocator) If you use only one allocator, you have a bad management or in the speed of equal size elements, or with a wide variety of elements. If you use two allocators, the memory freed by an allocator can't be used by the other, and the memory consumption is very high, and when decrease the number of elements to manage, the memory don't decrease. These problems are specially important in two environments : a) When you have a limited resources, as occurs in the mobile phones, pads ... b) When the programs must run continuously in a multitask environment The solution is the suballocator. It is a mechanism for to manage in a fast way a greater number (hundred millions) of elements with the same size. The suballocator is a layer over the allocator (any allocator with the STL interface). The suballocator receives an allocator as template parameter. When the suballocator needs memory, request memory from the allocator, and when the memory is not used, is returned to the allocator. The suballocator present the same interface than the STL allocator. Form the view point of the data structures, the suballocator is other allocator The suballocator always return the first element free. This improve the cache performance and the speed of the data structures. This simple memory schema permit to the allocators return memory to the Operating System and decrease the memory used by the program, as demonstrate the programs in the benchmarks, and you can see in the benchmark point. With the suballocator a) We have a very *fast allocation* (3 times faster than GCC 4.6 std::allocator, 3.5 times faster than Visual Studio 10 std::allocator ) b) Return memory to the allocator, for to be used by others types of data. Many allocators, return this memory to the Operating System, and *decrease the memory used by the program * c) You *can use with any allocator* if according with the STL definition. The suballocator provides speed and memory management to any allocator. d) In the insertion in a std::set<uint64_t> , the time spent by the allocator is around 1%, but the suballocator save around 35% of time . The suballocator always provide the first position free, This provide us a very compact data are, which *improve the cache performance* All the information showed here is explained and detailed in the point Suballocator. All the information is extracted from the programs in the benchmarks folder. *COUNTERTREE + SUBALLOCATOR* The join of the two ideas provide us data structures with a suballocator built-in. They are, in the namespace cntree, the vector_tree_pool, set_pool, multiset_pool,map_pool and multimap_pool, with identical interface than the STL classes but better performance. Tray it. It fast, useful and easy to understand and use,. They are the STL classes with a few additional functions. I had checked this code with GCC 4.6 (32 and 64) , CLANG/LLVM 3.0 and Visual Studio 1010 (32 and 64). If you find any error or problem in the code , the documentation or in any other part ( as friendly do Mr Rene Rivera in the first version). Please mail me ( fjtapia(a)gmail.com) or if you mail Boost, please insert [countertree] in the head of the message. Some days I have not time to read all messages arrived to my mail, but if I see that I detect and respond first. If you have some idea, or have any comment, please mail me, always two legs run more than only one in the pursuit of the goal, to be useful to the community of programmers in the same way than our predecessors had been useful to us. Sincerely yours Francisco Tapia fjtapia(a)gmail.com

7 19

[release] scope_exit, local_function, utility/identity_type, and functional/overloaded_function
by lcaminiti 02 May '12

02 May '12

Hello release managers, I've been working in the trunk on a few libraries which are almost ready to be released: a) When is the release date? b) What do I have to do to merge into release? (This will be my 1st release merge :) ). 1) ScopeExit (improved) I'm waiting on MVSC 9 and 10 tests to cycle to make sure they all pass. Other compilers OK. 2) Utility/IdentityType (new) Should be ready to be merged into release. 3) Functional/OverloadedFunction (new) Should be ready to be merged into release. 4) LocalFunction (new) I'm making final fixes for some tests on some of compilers. Hopefully, I'll be done in 2 weeks max. For all of those, I've followed the checklist so I've run the code inspection tool, updated all docs, librariers.htm, and maintainers.txt. Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-release-scope-exit-local-function-… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 9

Trac Default Version
by Olaf van der Spek 02 May '12

02 May '12

Hi, Why's the default version when submitting a ticket still 1.48? -- Olaf

2 1

[uuids] On boost::uuids::uuid operator == performance.
by Michael Kochetkov 02 May '12

02 May '12

Hello. I would like to discuss a performance issue with boost::uuids::uuid operator ==. Let us consider the following program: --------------------------------------------------- #include <boost/uuid/uuid.hpp> #include <boost/uuid/uuid_generators.hpp> int main() { boost::uuids::uuid id1((boost::uuids::random_generator()())), id2((boost::uuids::random_generator()())); return id1 == id2; // we will consider this line } --------------------------------------------------- That is compiled with maximum optimizations the following way with Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86: cl -EHsc -Ox -GL -Ob2 -Oi -Fa -I..\3dparty\boost_1_48_0 m051.cpp boost uses the following comparison operator: inline bool operator==(uuid const& lhs, uuid const& rhs) /* throw() */ { return std::equal(lhs.begin(), lhs.end(), rhs.begin()); } which end up with the following code: lea edx, DWORD PTR _id2$[esp+92] lea ecx, DWORD PTR _id1$[esp+108] lea eax, DWORD PTR _id1$[esp+92] call ?_Equal@std@@YA_NPBE00@Z ; std::_Equal The whole story looks the following way (the code above plus std::_Equal call expansion): 0117C6AB lea edx,[esp+24h] 0117C6AF lea ecx,[esp+48h] 0117C6B3 lea eax,[esp+38h] 0117C6B7 call 01171000 01171000 push esi 01171001 mov esi,eax 01171003 sub ecx,esi 01171005 push edi 01171006 cmp ecx,4 01171009 jb 01171024 0117100B jmp 01171010 0117100D lea ecx,[ecx] 01171010 mov eax,dword ptr [esi] 01171012 cmp eax,dword ptr [edx] 01171014 jne 01171028 01171016 sub ecx,4 01171019 add edx,4 0117101C add esi,4 0117101F cmp ecx,4 01171022 jae 01171010 01171024 test ecx,ecx 01171026 je 01171073 01171028 movzx eax,byte ptr [esi] 0117102B movzx edi,byte ptr [edx] 0117102E sub eax,edi 01171030 jne 01171063 01171032 cmp ecx,1 01171035 jbe 01171073 01171037 movzx eax,byte ptr [esi+1] 0117103B movzx edi,byte ptr [edx+1] 0117103F sub eax,edi 01171041 jne 01171063 01171043 cmp ecx,2 01171046 jbe 01171073 01171048 movzx eax,byte ptr [esi+2] 0117104C movzx edi,byte ptr [edx+2] 01171050 sub eax,edi 01171052 jne 01171063 01171054 cmp ecx,3 01171057 jbe 01171073 01171059 movzx eax,byte ptr [esi+3] 0117105D movzx ecx,byte ptr [edx+3] 01171061 sub eax,ecx 01171063 sar eax,1Fh 01171066 or eax,1 01171069 xor edx,edx 0117106B test eax,eax 0117106D pop edi 0117106E sete al 01171071 pop esi 01171072 ret 01171073 xor eax,eax 01171075 xor edx,edx 01171077 test eax,eax 01171079 pop edi 0117107A sete al 0117107D pop esi 0117107E ret I do understand that the boost::uuids::uuid implementation is conceptually correct and inoculate the best programming practices. But the following equivalent is too much faster (you may probably want to ensure a proper alignment for some processor architectures or even get even faster 64-bit version): inline bool comp(const boost::uuids::uuid& l, const boost::uuids::uuid& r) { return *reinterpret_cast<const uint32_t*>(l.data) == *reinterpret_cast<const uint32_t*>(r.data) && *reinterpret_cast<const uint32_t*>(l.data+4) == *reinterpret_cast<const uint32_t*>(r.data+4) && *reinterpret_cast<const uint32_t*>(l.data+8) == *reinterpret_cast<const uint32_t*>(r.data+8) && *reinterpret_cast<const uint32_t*>(l.data+12) == *reinterpret_cast<const uint32_t*>(r.data+12); } the assembler output is: mov ecx, DWORD PTR _id1$[esp+92] cmp ecx, DWORD PTR _id2$[esp+92] jne SHORT $LN37@main mov edx, DWORD PTR _id1$[esp+96] cmp edx, DWORD PTR _id2$[esp+96] jne SHORT $LN37@main mov eax, DWORD PTR _id1$[esp+100] cmp eax, DWORD PTR _id2$[esp+100] jne SHORT $LN37@main mov ecx, DWORD PTR _id1$[esp+104] cmp ecx, DWORD PTR _id2$[esp+104] jne SHORT $LN37@main mov eax, 1 jmp SHORT $LN40@main $LN37@main: xor eax, eax $LN40@main: movzx eax, al that the question comes: is boost supposed to be used in commercial applications or it is just a testing area for some concepts? You have probably never thought of the fact that Debug (unoptimized configurations) are sometimes just unusable with such approach on real (big) data. If you are interested you may want to compile the program above this way and see the resulting code: cl -EHsc -Zi -Fa -I..\3dparty\boost_1_48_0 m051.cpp Thank you in advance for your considerations. -- Michael Kochetkov

7 27

[uuid] Unused variable warnings
by Andrey Semashev 02 May '12

02 May '12

Hi, With recent versions of boost I get lots of warnings like the following: /.../boost/uuid/seed_rng.hpp: In member function ‘void boost::uuids::detail::seed_rng::sha1_random_digest_()’: /.../boost/uuid/seed_rng.hpp:157:24: warning: variable ‘not_used’ set but not used [-Wunused-but-set-variable] I'm using GCC 4.6 with -Wall. It's trivial to mask this warning out by attaching __attribute__((unused)) to the variable, which I've done locally. Ok to commit?

2 2

Recommended way of dealing with windows.h in headers?
by Mathias Gaunard 02 May '12

02 May '12

What's the recommended way to deal with windows.h in Boost? I see a lot of libraries doing stuff like #if defined( BOOST_USE_WINDOWS_H ) # include <windows.h> #endif namespace boost { namespace detail { #if !defined( BOOST_USE_WINDOWS_H ) extern "C" void __stdcall Sleep( unsigned long ms ); #endif So should libraries just declare all symbols themselves? But here the declaration is wrong, it misses __declspec(dllimport) for example when the runtime CRT is used, unnecessarily requiring import libraries. WINBASEAPI/WINADVAPI macros could be used to fix that. There is also the file <boost/detail/win/basic_types.hpp> that contains a few of the types, but it doesn't seem to be used that much except by other files in detail/win, and then again they don't re-use WINAPI and other macros. It also seems to be lacking the WINBASEAPI/WINADVAPI macros. Also, why couldn't headers simply include <windef.h> then <winbase.h>? Does that cause problems too?

3 2

[Smart Ptr] make_shared slower than shared_ptr(new) on VC++9 (and 10) with fix
by Ivan Erceg 02 May '12

02 May '12

Hi all, Before I switch to using boost::make_shared<> I wanted to test its purported performance advantage. I created a simple benchmark for measuing raw allocation throughput for 3 classes of different sizes with a common base class (constructors and destructors trivial). The number of allocations was set to 40,000,000 as it was roughly giving me 10 seconds running time per test. Unfortunatelly it turns out that on VC++9 (release target with default optimizations) boost::make_shared is significantly slower than simply doing boost::shared_ptr(new). Here's the benchmark output: TestBoostMakeShared 10.577s 3.78179e+006 allocs/s TestBoostSharedPtrNew 8.907s 4.49085e+006 allocs/s As you can see boost::make_shared is over 15% slower than boost::shared_ptr(new) idiom. Having available VC++10 compiler as well I then compared these results with std::shared_ptr and std::make_shared implementations that come with that compiler (but not VC++9). Here are the results: TestBoostMakeShared 9.688s 4.12882e+006 allocs/s TestBoostSharedPtrNew 8.252s 4.84731e+006 allocs/s TestStdMakeShared 5.07s 7.88955e+006 allocs/s TestStdSharedPtrNew 8.159s 4.90256e+006 allocs/s While std::shared_ptr(new) performs about the same as boost::shared_ptr(new), std::make_shared really blows away boost::make_shared and both shared_ptr(new) tests, being almost twice as fast as boost::make_shared. I then profiled the boost::make_shared test to see what's the biggest performance bottleneck when compared to boost::shared_ptr(new) profiler run. The culprit was immediately obvious: boost::make_shared test was spending above 25% of its time in "type_info::operator==(class type_info const &) const" function. This function was being called indirectly from boost::make_shared through boost::get_deleter. After digging some more through the implementation I came to the conclusion that, in this particular case, we are guaranteed to always be requesting deleter for the right class (namely T from boost::make_shared<T>). Since boost::shared_ptr doesn't have a way to retrieve the deleter without using RTTI I decided to add one and use it from an alternative boost::make_shared. So I did the following: 1. I added a virtual function to detail::sp_counted_base (detail\sp_counted_base_w32.hpp): virtual void * get_raw_deleter( ) = 0; 2. I implemented get_raw_deleter() function in sp_counted_impl_p (detail\sp_counted_impl.hpp): virtual void * get_raw_deleter( ) { return 0; } 3. I implemented get_raw_deleter() function in sp_counted_impl_pd (detail\sp_counted_impl.hpp): virtual void * get_raw_deleter( ) { return &reinterpret_cast<char&>( del ); } 4. I implemented get_raw_deleter() function in sp_counted_impl_pda (detail\sp_counted_impl.hpp): virtual void * get_raw_deleter( ) { return &reinterpret_cast<char&>( d_ ); } 5. I added the following function to detail::shared_count: void * get_raw_deleter( ) const { return pi_? pi_->get_raw_deleter( ): 0; } 6. I added the following function to shared_ptr<>: void * _internal_get_raw_deleter( ) const { return pn.get_raw_deleter( ); } 7. I made a separate copy of boost::make_shared function and replaced a single line from: boost::detail::sp_ms_deleter< T > * pd = boost::get_deleter< boost::detail::sp_ms_deleter< T > >( pt ); to: boost::detail::sp_ms_deleter< T > * pd = static_cast<boost::detail::sp_ms_deleter< T > *>(pt._internal_get_raw_deleter()); Benchmarking the results afterwards gave me the following results on VC++9: TestBoostSharedPtrNew 9.204s 4.34594e+006 allocs/s TestBoostMakeShared 10.499s 3.80989e+006 allocs/s TestBoostMakeSharedAlt 7.831s 5.1079e+006 allocs/s My changes translated into almost 35% improvement in allocation speed over the current implementation of boost::make_shared. Or to put it differently, they amount to 25+% decrease in running time as we could have supposed from the profiling results. Results on VC++10 are similar: TestBoostSharedPtrNew 8.487s 4.71309e+006 allocs/s TestBoostMakeShared 9.609s 4.16276e+006 allocs/s TestStdSharedPtrNew 8.283s 4.82917e+006 allocs/s TestStdMakeShared 5.039s 7.93808e+006 allocs/s TestBoostMakeSharedAlt 6.802s 5.88062e+006 allocs/s VC++10's std::make_shared is still much faster (almost 35% faster than boost::shared_ptr) and we will be switching to it once we switch to VC++10. But in the meantime it seems to me that boost::make_shared should be fixed to improve the performance. Again, this is only one compiler and other compilers might not have such a severe RTTI performance issue but I still think it would be well worth avoiding unnecessary calls to RTTI during performance-relevant operations such as heap allocations. The testing and changes were done on Boost 1.48.0 but I compared Smart Ptr library sources with Boost 1.49.0 and the above changes should work there equally well. Thanks, Ivan

15 40

[ANN] ODB C++ ORM 2.0.0 released, adds support for C++11, polymorphism
by Boris Kolpackov 02 May '12

02 May '12

I am pleased to announce the release of ODB 2.0.0. ODB is an open source object-relational mapping (ORM) system for C++. It allows you to persist C++ objects to a relational database without having to deal with tables, columns, or SQL and without manually writing any of the mapping code. ODB provides a Boost profile which allows you to seamlessly use value types (date_time), containers (optional, unordered), and smart pointers (shared_ptr, weak_ptr) from Boost in your persistent classes. Major new features in this release: * Support for C++11 which adds integration with the new C++11 standard library components, including smart pointers and containers. Now you can use std::unique_ptr and std::shared_ptr as object pointers (their lazy versions are also provided). For containers, support was added for std::array, std::forward_list, and the unordered containers. * Support for polymorphism which allows you to persist, load, update, erase, and query objects of derived classes using their base class interfaces. Persistent class hierarchies are mapped to the relational database model using the table-per-difference mapping. * Support for composite object ids which are translated to composite primary keys in the relational database. * Support for the NULL semantics for composite values. This release has also been tested with GCC 4.7 and Clang 3.0 with the ODB compiler now supporting the GCC 4.7 series plugin interface. A more detailed discussion of these features can be found in the following blog post: http://www.codesynthesis.com/~boris/blog/2012/05/02/odb-2-0-0-released/ For the complete list of new features in this version see the official release announcement: http://www.codesynthesis.com/pipermail/odb-announcements/2012/000013.html ODB is written in portable C++ and you should be able to use it with any modern C++ compiler. In particular, we have tested this release on GNU/Linux (x86/x86-64), Windows (x86/x86-64), Mac OS X, and Solaris (x86/x86-64/SPARC) with GNU g++ 4.2.x-4.7.x, MS Visual C++ 2008 and 2010, Sun Studio 12, and Clang 3.0. The currently supported database systems are MySQL, SQLite, PostgreSQL, Oracle, and SQL Server. More information, documentation, source code, and pre-compiled binaries are available from: http://www.codesynthesis.com/products/odb/ Enjoy, Boris

1 0

Re: [boost] [preprocessor] Sequences vs. All Other Data Structures
by Brian Wood 02 May '12

02 May '12

Paul Mensonides: > As some sort of technological preview? It is not portable enough to be > used within Boost, though perhaps a slew of regression failures will cause > that to change (unlikely). <rant>MS, in particular, is too busy taking it > upon themselves to "ensure C++ is relevant" to prioritize implementing the > language.</rant> Also, one of the principles of Chaos is to have > absolutely zero compiler workarounds, and that would have to stay if it > was ever part of Boost. Given your desire to avoid compiler workarounds, an on line code generator may be helpful. One of the happy results of going on line is kissing compiler workarounds good-bye. I've worked on the distribution of code generated by an on line code generator -- http://webEbenezer.net/build_integration.html . You're welcome to use that as a starting point if you like. Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net

4 4

Review request: extended complex number library
by Matthieu Schaller 02 May '12

02 May '12

Dear all, Following the comments from V. Escriba, I formally propose my complex number library for review. The library is an extension of the std::complex class addressing two issues: - The standard does not guaranty the behaviour of the complex class if instantiated with types other than float/double/long double. - Some calculation where pure imaginary numbers (i.e. multiples of sqrt(-1)) appear are unnecessarily slowed down due to the lack of support for these numbers. The code I submit contains two interleaved classes boost::complex and boost::imaginary which can be instantiated with any type T provided T overloads the usual arithmetic operators and some basic (real) mathematical functions depending on which complex function will be used. It is thus an extended version of Thorsten Ottosen's n1869 proposal (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1869.html) Performance tests show some non-negligible speed-ups compared to std::complex for calculations where pure imaginary numbers are involved. A speed-up of 25% has been observed when solving the Schroedinger equation explicitly on a regular mesh and some comparable figures can be observed when computing the Mandelbrot set (the two examples snippets provided in the archive). Furthermore, the functions (sin(), exp(), log(),...) involving boost::imaginary numbers are more precise than their equivalent using a std::complex with the real part set to 0. The code and (doxygen) documentation is available in the repository http://code.google.com/p/cpp-imaginary-numbers/ A comprehensive zip archive can be found in the "download" and the code can also be checked-out via the SVN repository. The archive contains the class header, two examples, a comprehensive precision test, a brute-force performance test and the documentation. I'd be happy to answer any question from your side and to provide more detailed information if required. Regards, Matthieu -- Matthieu Schaller PhD student - Durham University

8 23