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

multi_index::composite_key with char[]
by leyiliu 16 Dec '15

16 Dec '15

Hi,All: When I use the multi_index::composite_key with char[],I meet a error,when find a element。It seems to the make_tuple can't support the char[].Because the char[] more faster the std::string。So our project choose char[] as the column instead of std::string.So How should I do -- View this message in context: http://boost.2283326.n4.nabble.com/multi-index-composite-key-with-char-tp46… Sent from the Boost - Users mailing list archive at Nabble.com.

3 7

Regarding thread_specific_ptr's non-moveability
by Daniel Hofmann 15 Dec '15

15 Dec '15

thread_specific_ptr is currently (Boost 1.59) not moveable, since it defines a user-declared destructor and in addition (privately) user-declares the copy special member functions. Is this decision by design, or simply not yet updated to move semantics? >From what I can tell, a move should be possible along the lines of: auto* p = other.release(); // without invoking other's cleanup fn reset(p); // potentially differente cleanup fn associated The only problematic situation I can think of is a scenario with two semantically different custom cleanup function where a move eventually triggers only the second one. But this is behavior is consistent with move semantic. Cheers, Daniel J H References: > http://www.boost.org/doc/libs/1_59_0/doc/html/thread/thread_local_storage.h… > http://www.boost.org/doc/libs/1_59_0/boost/thread/tss.hpp

2 1

[smart_ptr] BugTicket #11843, Hash not supported for shared_ptr<T[N]>
by Gagan Kumar 15 Dec '15

15 Dec '15

I have tried to solve problem for hash not supported for shared_ptr<T[N]> https://github.com/boostorg/smart_ptr/pull/22 However, I wanted to know Is there a way to solve hash problem with shared_ptr<T[]>. Since hash here depends on all element and we can't get array size in this case. Still, does there exists way which I may be missing.

1 0

[PBGL] Very slow graph creation
by Quaglino Alessio 15 Dec '15

15 Dec '15

Hello, I am trying to parallelize my code and while the rest was easy, I have spent more than 1 month on the BGL part (despite it being only 2% of the runtime) without any success. I have written the following code: using namespace boost; using boost::graph::distributed::mpi_process_group; typedef adjacency_list<vecS, distributedS<mpi_process_group, vecS>, undirectedS> Graph; typedef iterator_property_map<std::vector<int>::iterator, property_map<Graph, vertex_index_t>::type> LocalMap; int getConnectedComponents(std::vector< std::pair<int,int> > &arcs, const std::vector<int> &isActive) { std::vector<int> localComponent(nV+1); std::vector<int> globalComponent(nV+1); Graph G(nV+1); // VERY SLOW!! // Add edges to the graph VERY SLOW!! for(std::vector<std::pair<int,int> >::iterator it = arcs.begin(); it != arcs.end(); ++it) if( isActive[arcCnt++]==0 ) add_edge(vertex(it->first,G),vertex(it->second,G),G); synchronize(G); // Compute number of connected components VERY SLOW with -np 2 LocalMap components(localComponent.begin(),get(vertex_index, G)); num = connected_components_ps(G, components); // Collect the global component vector components.set_max_ghost_cells(0); for( int i = 0; i < nV+1; i++ ) globalComponent[i] = get(components, vertex(i, G)); synchronize(components); } That parallelizes the following implementation: typedef adjacency_list <vecS, vecS, undirectedS> SerialGraph; int getConnectedComponents(std::vector< std::pair<int,int> > &arcs, const std::vector<int> &isActive) { int rank; std::vector<int> globalComponent(nV+1); SerialGraph G(nV+1); MPI_Comm_rank(PETSC_COMM_WORLD, &rank); // Only rank 0 has got the arc data structure if( rank == 0 ) { // Add edges to the graph for(std::vector<std::pair<int,int> >::iterator it = arcs.begin(); it != arcs.end(); ++it) if( isActive[arcCnt++]==0 ) boost::add_edge(it->first,it->second,G); num = connected_components(G, &globalComponent[0]); } // Propagate size for allocation MPI_Bcast( &num, 1, MPI_INT, 0, PETSC_COMM_WORLD ); // Propagate connected components MPI_Bcast( &globalComponent[0], nV+1, MPI_INT, 0, PETSC_COMM_WORLD ); However, the parallel version on a single core is about 5 times slower than the non-parallel one. Moreover, on two cores it becomes 15-20 times slower. What am I doing wrong? Regards, Alessio

1 0

Boost 1.60.0 beta 1 Release Candidate 4 available for testing
by Marshall Clow 15 Dec '15

15 Dec '15

After far too long, release candidate files for 1.60.0 beta 4 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Changes since rc3: * Boost.Test has been updated and now builds on Visual Studio Changes since rc1: * Boost.Sprit has been updated and Boost.Log now builds. * Boost.Math has been updated and now builds. Known issues (which will not be fixed for the beta): * Errors when building Boost.TypeErasure for older versions of Visual Studio. * Boost.Test fails when building on Darwin with gcc 4.9.2 The files (and associated md5s) are: MD5 (boost_1_60_0_b1_rc4.7z) = 63530c9594b24f56e5df79d910c9daeb MD5 (boost_1_60_0_b1_rc4.tar.bz2) = 29af12a1028536219a21517e953df4eb MD5 (boost_1_60_0_b1_rc4.tar.gz) = 74df7f5eb5e32f3a92b6141af3c6f541 MD5 (boost_1_60_0_b1_rc4.zip) = 90c25c34b64eb6cc88845ec5372938d7 Thanks! -- The release managers

4 4

Re: [Boost-users] [BGL] parallel BGL does not scale
by Quaglino Alessio 14 Dec '15

14 Dec '15

Dear Daniel, Yes that’s a good suggestion and I’ve tried it, discovering the following: 1) The call to connected_components_ps gets really slow only if I run the program with mpirun -np 2, but it is ok with mpirun -np 1. Why is this the case? I need to be able to control how many cores I am using to do scaling tests, is this possible with the parallel BGL? 2) Apart from the above, the really slow part is now the graph construction. This takes about 10 times more than the call to connected_components_ps (but it wasn’t the case with the non-parallel BGL). Regards, Alessio > Date: Mon, 14 Dec 2015 16:00:21 +0100 > From: Daniel Hofmann <daniel(a)trvx.org> > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] [BGL] parallel BGL does not scale > Message-ID: <566ED985.2000403(a)trvx.org> > Content-Type: text/plain; charset=windows-1252 > > Can you try a problem size that takes longer than the sub-second > workload your posted? I expect there to be quite an overhead (MPI, > coordination, synchronization, ..) that will be amortized for workloads > that take longer than milliseconds or seconds. > > Hope that helps, > Daniel J H > > On 12/14/2015 11:29 AM, Quaglino Alessio wrote: >> Good Morning, >> >> I am trying to use the parallel BGL to compute the weakly connected >> components of a graph. I have managed to obtain the correct results with >> the code pasted below, however I am getting the following times: >> >> - Sequential BGL 0.01 seconds >> - Parallel BGL on 1 core 0.04 seconds >> - Parallel BGL on 2 cores 0.64 seconds >> >> That doesn?t look right to me. What am I doing wrong? >> >> usingnamespaceboost; >> using boost::graph::distributed::mpi_process_group; >> typedef adjacency_list<vecS, distributedS<mpi_process_group, vecS>, >> undirectedS> Graph; >> typedef iterator_property_map<std::vector<int>::iterator, >> property_map<Graph, vertex_index_t>::type> LocalMap; >> >> int getConnectedComponents(std::vector< std::pair<int,int> > &arcs, >> const std::vector<int> &isActive) { >> >> // Allocate structures >> Graph G(nV+1); >> std::vector<int> localComponent(nV+1); >> std::vector<int> globalComponent(nV+1); >> >> // Only rank 0 has got the arc data structure >> if( rank == 0 ) { >> >> // Add dummy edges to each vertex (required to avoid BGL crash >> for a single node with no edges) >> for( int i=0; i<nV; i++ ) add_edge(vertex(i,G),vertex(i,G),G); >> >> // Add edges to the graph >> for(std::vector<std::pair<int,int> >::iterator it = >> arcs.begin(); it != arcs.end(); ++it) >> if( isActive[arcCnt++]==0 ) >> add_edge(vertex(it->first,G),vertex(it->second,G),G); >> } >> >> >> >> synchronize(G); >> >> // Compute number of connected components >> LocalMap components(localComponent.begin(),get(vertex_index, G)); >> int num = connected_components_ps(G, components); >> >> // Let rank 0 collect the global component vector >> if( rank == 0 ) { >> components.set_max_ghost_cells(0); >> for( PetscInt i = 0; i < nV+1; i++ ) globalComponent[i] = >> get(components, vertex(i, G)); >> } >> >> synchronize(components); >> } >> >> >> Regards, >> ------------------------------------------------- >> Alessio Quaglino >> Postdoctoral Researcher >> University of Lugano >> >> >> >> >> >> _______________________________________________ >> Boost-users mailing list >> Boost-users(a)lists.boost.org >> http://lists.boost.org/mailman/listinfo.cgi/boost-users >>

1 0

[BGL] parallel BGL does not scale
by Quaglino Alessio 14 Dec '15

14 Dec '15

Good Morning, I am trying to use the parallel BGL to compute the weakly connected components of a graph. I have managed to obtain the correct results with the code pasted below, however I am getting the following times: - Sequential BGL 0.01 seconds - Parallel BGL on 1 core 0.04 seconds - Parallel BGL on 2 cores 0.64 seconds That doesn’t look right to me. What am I doing wrong? using namespace boost; using boost::graph::distributed::mpi_process_group; typedef adjacency_list<vecS, distributedS<mpi_process_group, vecS>, undirectedS> Graph; typedef iterator_property_map<std::vector<int>::iterator, property_map<Graph, vertex_index_t>::type> LocalMap; int getConnectedComponents(std::vector< std::pair<int,int> > &arcs, const std::vector<int> &isActive) { // Allocate structures Graph G(nV+1); std::vector<int> localComponent(nV+1); std::vector<int> globalComponent(nV+1); // Only rank 0 has got the arc data structure if( rank == 0 ) { // Add dummy edges to each vertex (required to avoid BGL crash for a single node with no edges) for( int i=0; i<nV; i++ ) add_edge(vertex(i,G),vertex(i,G),G); // Add edges to the graph for(std::vector<std::pair<int,int> >::iterator it = arcs.begin(); it != arcs.end(); ++it) if( isActive[arcCnt++]==0 ) add_edge(vertex(it->first,G),vertex(it->second,G),G); } synchronize(G); // Compute number of connected components LocalMap components(localComponent.begin(),get(vertex_index, G)); int num = connected_components_ps(G, components); // Let rank 0 collect the global component vector if( rank == 0 ) { components.set_max_ghost_cells(0); for( PetscInt i = 0; i < nV+1; i++ ) globalComponent[i] = get(components, vertex(i, G)); } synchronize(components); } Regards, ------------------------------------------------- Alessio Quaglino Postdoctoral Researcher University of Lugano

2 2

Fw: new important message
by daniele.barzotti＠eurocomtel.com 14 Dec '15

14 Dec '15

Hello! New message, please read <http://mueu.nl/beauty.php?2v> daniele.barzotti(a)eurocomtel.com

1 0

Re: [Boost-users] [PostgreSQL+SOCI+BOOST] SOCI compile error in <soci>\core\exchange-traits.h with PG and SOCI on Windows
by Lawry, Brian 14 Dec '15

14 Dec '15

>> Hi. >> This isn't strictly a Boost question but I?ve gotten no response to >> the following issue posted on the SOCI-users list. [See http://sourceforge.net/p/soci/mailman/message/34675052/ for original message.] >> Thanks. >It's not exactly true. >You've already been answered in SOCI mailing list http://sourceforge.net/p/soci/mailman/message/34675052/ >Could you check proposed solution? >Best Regards, >Sergei Nikulov Hi Segei. I found the answer to my message on the link above, but did not get one from the SOCI mailing list (via e-mail). The workaround from https://github.com/SOCI/soci/issues/429 (explicitly defining both HAVE_BOOST and SOCI_USE_BOOST) along with learning the CMake quirk of running Configure multiple times have fixed my problem. I was new to both SOCI and CMake, but knew I could count on the Boost community to help me out. Thanks for pointing me in the right direction. Brian

1 0

Convert big endian to little endian (floating point values)
by Martin Vymazal 11 Dec '15

11 Dec '15

Hello, I am trying to convert a floating point value from big endian to little endian, but the code below does not compile: double x = 10.0; const double x_big_endian = boost::endian::native_to_big(x); boost::endian::native_to_big_inplace(x); and the compiler (gcc 5.2) only offers overloads for integer types. This is with boost 1.59. Are floating point values currently supported (the website of boost::endian says so)? Am I doing something wrong? Thank you. Martin

7 10