- Boost - lists.boost.org

Mutli index container - performance varation when erasing large amount of rows in different computers
by Avi Revivo 04 Nov '07

04 Nov '07

Hi All, I am trying to use boost Multi Index Container in my company product to replace an old container that gave the same functionallity but with bad performance. The mutli index container contains 2 non unique ordered indices. The mutli index container will be used to insert large amount of rows sequentially and an erase using one of the ordered indices that will evantually erase around 10,000 rows in one erase operation since the container will contain many duplicate values of the delete key. Testing the insertion of 10,000 rows takes around 60-80ms on a standard PC 3.2GHZ. On a HP G4 server (2 xeon 3.2 cpu's, 4Giga of memroy) the performance is a little better. In both cases the insertion is consistent. However, while erasing elements using one of the indices which incur the erase of 10,000 elements takes around 30ms on the standard PC. However, on the HP G4 the deletion is inconsistent and far worse. It takes between 200ms to 1.4 seconds on different deletion cycles. I am using the same products exactly on both machines. The HP G4 does not have a development envoirment installed on it, the standard pc have visual studio 2005 installed on it. Does anyone have any idea what may cause such exterme difference? Thanks in advance, Avi Nice Systems ltd. -- View this message in context: http://www.nabble.com/Mutli-index-container---performance-varation-when-era… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 6

[Report] 59 failures on trunk (2007-11-04)
by Douglas Gregor 04 Nov '07

04 Nov '07

Boost regression test failures Report time: 2007-11-04T11:49:19Z This report lists all regression test failures on release platforms. Detailed report: http://boost.org/regression/trunk/developer/issues.html 59 failures in 15 libraries conversion (3) fusion (7) gil (2) graph (3) math (1) numeric/interval (6) optional (4) python (1) regex (1) serialization (10) spirit (12) system (4) test (1) thread (3) wave (1) |conversion| lexical_cast_loopback_test: gcc-4.1.2_sunos_i86pc gcc-mingw-3.4.5 msvc-8.0 |fusion| filter_view: acc fused: acc fused_function_object: acc fused_procedure: acc make_fused: acc make_fused_function_object: acc make_fused_procedure: acc |gil| main: acc gcc-4.1.2_sunos_i86pc |graph| kolmogorov_max_flow_test: acc max_flow_test: acc transitive_closure_test: gcc-4.1.2_sunos_i86pc |math| test_bessel_j: darwin-4.0.1 |numeric/interval| mul: darwin-4.0.1 darwin-4.0.1 overflow: darwin-4.0.1 darwin-4.0.1 pi: darwin-4.0.1 darwin-4.0.1 |optional| optional_test: darwin-4.0.1 optional_test_ref: darwin-4.0.1 gcc-4.1.2_sunos_i86pc gcc-mingw-3.4.5 |python| exec: gcc-4.1.2_sunos_i86pc |regex| static_mutex_test: gcc-4.1.2_sunos_i86pc |serialization| test_exported_binary_archive: gcc-4.1.2_sunos_i86pc test_exported_binary_archive_dll: gcc-4.1.2_sunos_i86pc test_exported_text_archive: gcc-4.1.2_sunos_i86pc test_exported_text_archive_dll: gcc-4.1.2_sunos_i86pc test_exported_text_warchive: gcc-4.1.2_sunos_i86pc test_exported_text_warchive_dll: gcc-4.1.2_sunos_i86pc test_exported_xml_archive: gcc-4.1.2_sunos_i86pc test_exported_xml_archive_dll: gcc-4.1.2_sunos_i86pc test_exported_xml_warchive: gcc-4.1.2_sunos_i86pc test_exported_xml_warchive_dll: gcc-4.1.2_sunos_i86pc |spirit| custom_real_parser: acc darwin-4.0.1 darwin-4.0.1 gcc-4.1.2_sunos_i86pc gcc-mingw-3.4.5 msvc-8.0 custom_real_parser_debug: acc darwin-4.0.1 darwin-4.0.1 gcc-4.1.2_sunos_i86pc gcc-mingw-3.4.5 msvc-8.0 |system| error_code_test: acc error_code_test_dll: acc system_error_test: gcc-mingw-3.4.5 system_error_test_dll: gcc-mingw-3.4.5 |test| prg_exec_fail3: gcc-4.1.2_sunos_i86pc |thread| test_shared_mutex: gcc-4.1.2_sunos_i86pc test_shared_mutex_lib: acc gcc-4.1.2_sunos_i86pc |wave| testwave: gcc-mingw-3.4.5

1 0

Explanation of some problems we'll have with svnmerge
by David Abrahams 04 Nov '07

04 Nov '07

I think this only applies to the old branches created by cvs2svn. Anyway, worth knowing. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

[gil]:support for png palette images
by Andreas Pokorny 04 Nov '07

04 Nov '07

Hello, I just stumbled across missing support for PNG_COLOR_TYPE_PALETTE in gil. Somehow most monochrome images e.g. generated with gimp use PNG_COLOR_TYPE_PALETTE with two colors, instead of _GRAY with a bit depth of one. So I thought, maybe someone else already added support for such files? regards Andreas

1 0

Deterimining interest in: Optional Polymorphic Value object with Small Object optimization
by Corrado Zoccolo 04 Nov '07

04 Nov '07

Hi Following the recent interest in clone pointers and Polymorphic value object wrappers, I developed a slightly feature enriched Polymorphic Value object, that implements the small object optimization, and models the Optional Pointee concept. It follows a non-intrusive approach to cloning. The code can be found in the boost vault: *http://tinyurl.com/3a6sq8* Motivation: Dynamic polymorphism is a valuable but underestimated tool to the modern C++ programmer. It for example allows the implementation of type erasure and other techniques for physical decoupling. It is also unavoidable every time dynamic dispatching is needed. Unfortunately solutions based on it may often be slow, because traditional dynamic polymorphism is always paired with dynamic allocation. The proposed tool is targeted to ease the usage of dynamic polymorphism in modern C++ context, by giving value semantics to polymorphic objects, as well as providing a well known optimization technique to avoid dynamic allocation when the involved objects are small. Dynamic polymorphism, value semantics and small object optimization constitute a powerful receipt to solve such problems. As evidence boost::function, among the most valuable tools for type erasure and physical decoupling available in boost, is using all three of them. This tool is meant to be a low level tool, on which powerful abstractions like boost::function could be built easily. Basic Usage Example: #include "optional_poly.hpp" #include <iostream> // class with one virtual method but not virtual destructor // optional_poly will know the derived type, so it will call the correct destructor nevertheless struct B { virtual operator int() {return 0;}}; // lack of virtual destructor is intentional // Derived class, with side effect in destructor to show functionality, and overloaded virtual method to determine which one was called struct D : B { operator int() {return 1;} ~D() { std::cerr<<"Got it\n"; } void swap(D&) {} private: void operator=(D const &); }; // swap reachable via ADL. optional_poly will prefer (by default) this to implement its swap method. Using a trait, you can specify if a swap method or no swap at all should be used for a given type void swap(D& a,D& b) { a.swap(b); } int main() { // optional_poly constructor and operator= require that the static type match the dynamic one. // The following commented code is invalid, and will assert at runtime // const B& d=D(); // boost::optional_poly<B> z=d; // asserts, because optional_poly should be constructed with the concrete derived type // this is the correct way to initialize optional_poly. D must be derived from B (static assertion otherwise). boost::optional_poly<B> z=D(); std::cerr<<*z<<"\n"; // this prints 1 boost::optional_poly<B> s; // uninitialized (empty) optional_poly for interface B s.swap(z); // now s has a D, while z is empty std::cerr<<*s<<"\n"; // prints 1 return 0; } A bit more complex example: #include "optional_poly.hpp" #include <boost/none.hpp> #include <iostream> // we will show how simple callable objects can be returned easily and efficiently from a function (i.e. we implement a really small subset of boost::function) struct Callable { virtual void operator()() const=0; }; // inheritance is used here. This wrapper can host function pointers or functors seamlessly, exposing to the outside the Callable interface template<class T> struct MakeCallable: Callable { MakeCallable(const T& t) : val(t) {} T val; void operator()() const { val(); } }; void my_fun() { std::cout<<"got 1\n"; } struct MyFunc { void operator()() const { std::cout<<"got 2\n"; } }; // the function returning different Callable objects depending on the value of the parameter boost::optional_poly<Callable> foo(int i) { switch(i) { case 1: return MakeCallable<void (*)()>(my_fun); case 2: return MakeCallable<MyFunc>(MyFunc()); } return boost::none; } // main shows how foo() is invoked, and its result is used int main() { boost::optional_poly<Callable> c; for(int i=0;i<3; ++i) { c=foo(i); if(c) { std::cout<<"Going to call c for "<<i<<" ... ";(*c)(); } else { std::cout<<"empty c for "<<i<<"\n"; } } return 0; } Output: empty c for 0 Going to call c for 1 ... got 1 Going to call c for 2 ... got 2 Wasn't this easy? And this small example did not dynamically allocate any memory, because the Callable objects are all smaller than the small object threshold (default value is 128, can be overridden specifying a second template parameter to optional_poly, e.g. optional_poly<Callable,0> will always allocate from the heap). Sounds interesting for being submitted to boost? Corrado -- __________________________________________________________________________ dott. Corrado Zoccolo mailto: zoccolo(a)di.unipi.it PhD - Department of Computer Science - University of Pisa, Italy --------------------------------------------------------------------------

14 42

[1.35] Where to place PDF versions of docs?
by John Maddock 03 Nov '07

03 Nov '07

Folks I think we need to get organised with PDF's now that we have many more libraries with quickbook/boostbook docs. I don't particularly want these in SVN trunk: apart from anything else it needlessly bloats the download size if folks are happy with HTML versions. Previously I've placed these in the vault, but there's a file size limit there and the new Boost.Math PDF's are too large :-( Another alternative would be the sourceforge file release system, but I don't believe all developers have access to that? So.... how about we either have a directory in the "website" area of SVN for these, or else in the sandbox maybe? Thoughts? John.

10 15

[thread] Missing #include
by Andrey Semashev 03 Nov '07

03 Nov '07

Hi, I think boost/thread/pthread/shared_mutex.hpp in trunk is missing #include <boost/thread/thread.hpp>. Now it complains it doesn't know what this_thread is. I also noticed lots of warnings "unused variable 'res'" and alikes while compiling my projects with GCC 4.2.1 on OpenSUSE. These warnings mostly come from boost/thread/pthread/pthread_mutex_scoped_lock.hpp, boost/thread/pthread/once.hpp, boost/thread/pthread/mutex.hpp, boost/thread/pthread/condition_variable.hpp. I didn't investigate closely, though.

5 6

[Thread] Currently broken on Darwin?
by John Maddock 03 Nov '07

03 Nov '07

As well as none of the Boost.Thread tests currently building on Darwin, I'm seeing runtime errors from the regex tests of the kind: terminate called after throwing an instance of 'boost::system_error' Any ideas? Or better still planned fixes :-) Thanks, John.

2 1

Comments about N2320
by Yuval Ronen 03 Nov '07

03 Nov '07

Hi, After reading most of N2320, I have a few comments: * thread::id has operator== and operator!= declared twice. Once in namespace scope, and a second time inside class thread. Second time is with operator< and his friends. * Thread cancellation is new, and disable_cancellation/restore_cancellation are even newer. They are new for C++ programmers, and maybe new for *all* programmers (I never heard of a language with them). I'm not sure if it's a good idea to standardize them before we get some real-life experience with thread cancellation. * Time issues. To my eyes, it looks not pretty trying to get threading with time issues standardized before we have std::date_time. Making it a templated type not because we want genericity, but because we don't have the type we want yet, makes it look coerced. I think it's best to drop the time-related stuff, and add it properly together with date_time. Using the timed version of thread::join(), mutex::lock() and condition::wait() are very rare, and I think (hope) they can be implemented externally using native_handle(). * I see that you chose not go accept a mutex in condition's constructor. If that is so, why make the condition class templated, instead of only the wait() functions, as is in Boost.Thread? * If C++0x is going to have lambda support (is it?), then maybe the not-accepting-predicate overloads of condition::wait are no longer needed, and can be removed? I think the major reason why people use that overload is because they are too lazy to write a functor. With core support for lambda, it's a breeze. This will solve the other problem (mentioned in some other thread in this ML) about absolute vs. relative times. * Back then we had a discussion about unique_lock, which was never finished. I claim that there is no need for a state where mutex() != 0 && owns() == false, which means that defer_lock is not needed. There is one example in the document using defer_lock, which I think can be done in another way. That example goes like: Record& Record::operator=(const Record& r) { if (this != &r) { std::unique_lock<std::mutex> this_lock(mut, std::defer_lock); std::unique_lock<std::mutex> that_lock(r.mut, std::defer_lock); std::lock(this_lock, that_lock); // Both source and destination are locked // Safe to assign // ... } return *this; } If we change the first 3 lines of the 'if' to: std::lock(mut, r.mut); std::unique_lock<std::mutex> this_lock(mut, std::accept_ownership); std::unique_lock<std::mutex> that_lock(r.mut, std::accept_ownership); then it works without defer_lock. This allows us to: 1. Make unique_lock's interface simpler. 2. Make sizeof(unique_lock) smaller - no need for bool owns. 3. Make unique_lock more similar to unique_ptr, which makes it more intuitive. 4. Make std::lock simpler in the way that it doesn't need to accept locks, only mutexes. In general it seems you paid a lot of attention to being able to pass a lock instead of a mutex wherever possible. I think it's absolutely not necessary. It's an undue complication. * Other than that - very nice :) Yuval

15 48

[test] Sun 5.9 broken
by Beman Dawes 03 Nov '07

03 Nov '07

It looks like test is broken on Sun 5.9. Please fix immediately, or revert the change that caused the breakage. --Beman "../boost/test/impl/debug.ipp", line 420: Error: mkstemp is not a member of file level. "../boost/test/impl/debug.ipp", line 603: Error: getenv is not a member of file level. "../boost/test/impl/debug.ipp", line 856: Error: mkstemp is not a member of file level. "../boost/test/impl/debug.ipp", line 871: Error: exit is not a member of file level. "../boost/test/impl/debug.ipp", line 876: Error: getenv is not a member of file level. "../boost/test/impl/debug.ipp", line 885: Error: exit is not a member of file level. 6 Error(s) detected.

4 6