- Boost - lists.preview.boost.org

Problems with yield_k workaround. Still too slow.
by Marcello Pietrobon 07 Sep '13

07 Sep '13

Hello Boost team, As exposed by Gav Wood in http://boost.2283326.n4.nabble.com/Boost-Interprocess-Chronic-performance-o… Windows doesn't handle well the contest switching between threads. Basically if a thread is given a time to sleep for 1ms then the OS puts that thread on sleep for its entire timeslice (~20ms), no matter if the concurrent threads need a much shorter time to complete their job. The effect of this choice is that if you need to have two threads talking with each other through an emulated synchronization object, they take well 2 seconds to do just 100 back and forth. At least it seems to me that this problem arises only when *emulating * a synchronization object, which I understand is necessary, for example, in the interprocess library. It's not a problem of easy solution. There is an ongoing discussion in the interprocess library on how to fix this (see for example http://boost.2283326.n4.nabble.com/Boost-Interprocess-conditions-variables-… ) but clearly this is not a problem limited to it. The workaround http://www.boost.org/doc/libs/1_54_0/boost/smart_ptr/detail/yield_k.hpp improves the situation, yet only a bit. In order to isolate the problem I've run some tests using the interprocess library, with the example comp_doc_anonymous_conditionA.cpp (and B). This test is slowed down by this time of a factor ranging from 2 to 10, 100 or even 1000 or more times depending on how soon that infamous Sleep(1) is triggered. *The bottom line is that in yield_k.cpp we need to change the constant in the code * from 32 to *1000 * at least. I call this constant kMax: Here some test results, running XPsp3 on Xeon E5450 - dual socket 32bit CPU quad cores. 2GHz core speed. For test I changed comp_doc_anonymous_conditionA.cpp : that is 100000 iterations, while in comp_doc_anonymous_conditionB.cpp I've added the line just to emulate a job done by the thread while owning the mutex. That is: The results are (these numbers are representative of many tests I've run) : kMax = 32, jMax = 0 : time = 00:00:01.125000 kMax = 50, jMax = 0 : time = 00:00:00.403750 kMax = 100, jMax = 0 : time = 00:00:00.2803750 kMax = 65535, jMax = 0 : time = 00:00:00.203125 kMax ~= 64 is good kMax = 32, jMax = 10 : time = 00:00:32.843750 kMax = 100, jMax = 10 : time = 00:00:02.750000 kMax = 1000, jMax = 10 : time = 00:00:00.859375 kMax = 65535, jMax = 10 : time = 00:00:00.328125 kMax ~= 1000 is good kMax = 32, jMax = 100 : time = 00:04:01.953125 kMax = 50, jMax = 100 : time = 00:00:04.296875 kMax = 1000, jMax = 100 : time = 00:00:02.062500 kMax = 65535, jMax = 100 : time = 00:00:01.593750 kMax ~= 1000 is good If the job takes longer we need to increase kMax even more, but it seems that a value of 65535 cuts the problem and makes sure that a locked thread doesn't take most of the cpu time for more than one timeslice. -- View this message in context: http://boost.2283326.n4.nabble.com/Problems-with-yield-k-workaround-Still-t… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 6

[Graph] floyd_warshall crashes using optimzation
by Tim Keitt 06 Sep '13

06 Sep '13

I'm getting seg faults when I use optimization with floyd_warshall_shortest_paths. Without optimization it works fine. d here is defined as struct dmat_t { typedef std::vector<edge_weight_t> storage_t; dmat_t(vertex_t n) : ncol(n), storage(n * n) {} storage_t::iterator operator[](vertex_t row) { assert(row < ncol); storage.begin() + row * ncol; } vertex_t ncol; storage_t storage; }; Is this from 'inf' getting optimized out or how I defined dmat_t? Program received signal SIGSEGV, Segmentation fault. 0x000000000040162a in floyd_warshall_all_pairs_shortest_paths<boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, boost::no_property, boost::property<boost::edge_weight_t, double> >, edge_thinning_diameter_t::dmat_t, boost::adj_list_edge_property_map<boost::undirected_tag, double, double const&, unsigned long, boost::property<boost::edge_weight_t, double> const, boost::edge_weight_t>, std::less<double>, boost::closed_plus<double>, double, double> ( zero=<optimized out>, inf=<optimized out>, combine=..., compare=..., d=<synthetic pointer>, g=..., w=...) at /usr/include/boost/graph/floyd_warshall_shortest.hpp:115 115 d[*firstv][*firstv2] = inf; Also, it does not seem that floyd_warshall_shortest_paths is compatible with bundled properties. THK -- Timothy H. Keitt http://www.keittlab.org/

2 2

[atomic] atomic<int>::is_lock_free() returns false on iPad 4 (armv7s)
by Taylor Holliday 06 Sep '13

06 Sep '13

Hi, boost:atomic<int>::is_lock_free() returns false on iPad 4 (armv7s) but returns true on iPad 3 (armv7). Is this expected or did I build boost incorrectly? thanks! - Taylor W. Taylor Holliday, Owner/Founder Subatomic Software, San Francisco

3 3

[boost.chrono] Slow down process (if specifing c++11)
by Gaetano Mendola 06 Sep '13

06 Sep '13

Hi have tried the following code compiling it with gcc 4.6.3, with four combinations: 1) -O3 2) -O3 (commeting out the chrono call) 3) -O3 -std=c++0x 4) -O3 -std=c++0x (commenting out the chrono call) and I'm obtaining the following runtime values: 1) 8921 ms 2) 8915 ms 3) 9400 ms 4) 8933 ms as you can see the combination: "c++11 and chrono call" slows down the entire process. I have tried the same with gcc 4.8.1 and all times are more or less the same. At this point I'm not sure if it's a problem of chrono with gcc 4.6.3 or simply an issue of 4.6.3 disappeared in 4.8.1 series. Regards Gaetano Mendola Here the code I have used: #include <iostream> #include <boost/chrono.hpp> #include <sys/time.h> #include <math.h> int main() { cpu_set_t myAffinityMask; CPU_ZERO( &myAffinityMask ); CPU_SET(0, &myAffinityMask ); sched_setaffinity(0, sizeof(myAffinityMask), &myAffinityMask); volatile float* myMemoryA = new float[(1<<24)]; volatile float* myMemoryB = new float[(1<<24)]; struct timeval myStart; struct timeval myStop; struct timeval myResult; boost::chrono::time_point<boost::chrono::steady_clock> t1 = boost::chrono::high_resolution_clock::now(); gettimeofday(&myStart, 0); for (size_t i = 0; i < (1<<24); ++i) { myMemoryA[i] = i; myMemoryB[i] = i+1; } delete []myMemoryA; delete []myMemoryB; for (size_t j = 0; j < 100; ++j) { volatile float* myMemoryA = new float[(1<<24)]; volatile float* myMemoryB = new float[(1<<24)]; for (size_t i = 0; i < (1<<24); ++i) { myMemoryA[i] *= sqrtf(myMemoryB[i]); } delete []myMemoryA; delete []myMemoryB; } gettimeofday(&myStop, 0); timersub(&myStop,&myStart,&myResult); std::cout << "Time: " << myResult.tv_sec*1000 + myResult.tv_usec/1000.0 << std::endl; std::cout << "t1: " << t1 << std::endl; }

3 5

bjam assertion failure: does it really need stack alignment?
by Steve M. Robbins 05 Sep '13

05 Sep '13

Hi, A question for the bjam maintainers about https://svn.boost.org/trac/boost/ticket/8993 The file tools/build/v2/engine/function.c contains this check: static void check_alignment( STACK * s ) { assert( (size_t)s->data % sizeof( LIST * ) == 0 ); } However, things other than LIST* are allocated on the stack. For example expand_modifiers() allocates VAR_EDITS objects, whose size turns out not to be a multiple of sizeof(LIST*) on some architectures (m68k in the above ticket). Does check_alignment() still make sense? Thanks, -Steve

1 0

[thread] Can boost::this_thread::sleep_for() totally stop the thread?
by Klaim - Joël Lamotte 03 Sep '13

03 Sep '13

I'm having, sometime, trouble with a rare heisenbug (rare but appearing several times a week). I described it there: http://stackoverflow.com/questions/17918548/can-windows-totally-stop-a-thre… There I ask if it's possible for windows to totally stop a thread that is sleeping too often. As I'm using boost::thread for sleeping this specific thread that, for unknown reason, sometime totally stop working, I'm also wondering if the boost::this_thread() implementation could not be doing something that the OS might not like? ----- I'll report the content of the page here: Can Windows totally stop a thread if it's sleeping too often? I have a rare heisenbug in a multi-threaded application where the main thread, and only this thread, will just do nothing. As it's an heisenbug it's really hard to understand why this is happening. The main thread is basically just looping. In the loop, it check several concurrent priority queues which contain tasks ordered by time to be executed. It pop a task, see if it's time to execute it. If it's time, it will just schedule it into TBB's task scheduler (using a root task which is the parent of all other tasks). If it's not time, the task is pushed again in the priority queue. That's for one cycle. At the end of the cycle, the main thread is put to sleep for a very short time that I expect will be longer in practice but it's not really a problem, I just don't want it to use too much resources when not necessary. Litterally: static const auto TIME_SCHEDULED_TASKS_SPAWN_FREQUENCY = microseconds(250); while( !m_task_scheduler.is_exiting() ) // check if the application should exit { m_clock_scheduler.spawn_realtime_tasks(); // here we spawn tasks if it's time this_thread::sleep_for( TIME_SCHEDULED_TASKS_SPAWN_FREQUENCY ); } m_clock_scheduler.clear_tasks(); m_root_task.wait_for_all(); I have a special task that just log a "TICK" message each second. It is automatically rescheduling until the end of the program. However, when the heisenbug appear, I can see the "TICK" disappearing and the application not doing anything else than the work that occurs in non-main threads. So it appear that only the main thread is touched. The problem can come from different places, maybe in the scheduling logic, but then it's also the only thread that have a sleep call. That sleep is a boost::this_thread::sleep_for(). My question is: **Is it possible that Windows (7 64bit) consider the main thread to be sleeping often and decide that it should sleep for a longer period of time than asked or be definitely ended?** I expect that it is not possible but I would like to be sure. I didn't find any precision on this in online documentation so far. ----- I really suspect that the problem can't come from the sleeping function but I need to eliminate each potential source of problem to isolate it. Thanks for your time. Joel Lamotte

2 9

smart_ptr doesn't work when built with gcc on AIX
by Florent Guiliani 03 Sep '13

03 Sep '13

Hi, The Boost 1.54 smart_ptr atomic API code only supports the IBM xlC compiler under AIX. The attached patch make it also support the gcc compiler. I wanted to fill in a ticket for it on https://svn.boost.org/trac/boost/newticket but for some reason the ticket was classified as a spam by Trac. Anyone could help me here? One issue is the _sync*() APIs doesn't work when built optimized with GCC 4.8.0 on AIX 6.1 and 7.1 (and so the patch assume they don't work with all versions of GCC on AIX), so the patch undefine BOOST_SP_HAS_SYNC to prevent using those APIs. Another issue is the builtins.h file that Boost uses is missing, because it is installed as part of xlC. Under gcc, this patch will define assembly versions of the 2 builtins that are used in sp_counted_base_aix.hpp. Hope this gets through, -- Florent

1 0

[git] b2 headers not producing headers
by Ahmed Charles 02 Sep '13

02 Sep '13

I've tried following the instructions here: https://svn.boost.org/trac/boost/wiki/TryModBoost The 'b2 headers' command doesn't see to actually produce a boost directory. Is this supposed to work or is it just too soon?

3 2

[smart_ptr] Proposal to extract intrusive_ref_counter from Boost.Log
by Andrey Semashev 01 Sep '13

01 Sep '13

Hi, I'd like to move intrusive_ref_counter class from Boost.Log to Boost.SmartPtr. The class is intended to be used as a base class for a user's class that is intended to be used with intrusive_ptr. The class implements a reference counter and the related intrusive_ptr_add_ref/intrusive_ptr_release operations, so the user doesn't have to do that himself. Usage example: class my_class : public intrusive_ref_counter { }; intrusive_ptr< my_class > p = new my_class(); Besides just simplifying intrusive_ptr usage, the base class can be used as a sort of "void" as in shared_ptr< void >. I.e. intrusive_ptr< intrusive_ref_counter > can refer to object of any class that follows this protocol. Implementation: boost/log/utility/intrusive_ref_counter.hpp

5 10

Re: [boost] [utility] Proposal to extract some components from Boost.Log
by Daryle Walker 01 Sep '13

01 Sep '13

I don’t think you need a “constexpr_if.” You can unconditionally put BOOST_CONSTEXPR in the definition. This will unconditionally add “constexpr” to the member operator (for C++11 systems), which will be ignored if the compiler determines that the attached function (or a particular call) is disqualified from being used in constant expressions. So any extra preprocessor work, or a variant macro, is unnecessary. Sent from Windows Mail From: Andrey Semashev Sent: ‎Sunday‎, ‎September‎ ‎01‎, ‎2013 ‎4‎:‎40‎ ‎AM To: boost(a)lists.boost.org On Sunday 01 September 2013 03:27:06 Daryle Walker wrote: > > Date: Wed, 28 Aug 2013 12:14:51 +0400 > > From: andrey.semashev(a)gmail.com > > > > 1. BOOST_EXPLICIT_OPERATOR_BOOL() macro for defining explicit operator > > bool() for a class. > > a. It isn't marked "constexpr." I can add that myself before using > "BOOST_EXPLICIT_OPERATOR_BOOL" in "boost/rational.hpp," but what happens if > someone corrects it in "explicit_operator_bool.hpp"? Will the (temporary) > double definition cause an error? Well, since there isn't a constexpr_if or something, I don't see a way to add it to BOOST_EXPLICIT_OPERATOR_BOOL. I could add BOOST_EXPLICIT_OPERATOR_BOOL_PP(pre, post), which would add pre() and post() before and after the operator signature. For example:

3 4