- Boost - lists.boost.org

[boost 1.61 - [thread] Request for permission to merge
by Vicente J. Botet Escriba 31 Mar '16

31 Mar '16

Hi, I would like to merge once it is announced that the release branch is open for fixes a minor fix https://svn.boost.org/trac/boost/ticket/11562 - (condition_variable_any::wait_until + recursive_mutex + steady_clock) timer expires after computer time is set forward on Ubuntu 64-bit add missing template parameter in wait_until. https://github.com/boostorg/thread/commit/9db70b803d8f45632cd92cd61ab019c1f… and the rollback of something that resulted in a regression https://svn.boost.org/trac/boost/ticket/12049 - Assertion failure from detached threads during shutdown rollback BOOST_THREAD_PATCH. https://github.com/boostorg/thread/commit/47357de276fe4fc01469f34c1dbf8b26f… Best, Vicente

1 1

Re: [boost] [filesystem] Horrible documentation
by Tatsuyuki Ishi 31 Mar '16

31 Mar '16

> From: Edward Diener <eldiener(a)tropicsoft.com> > Date: Wed, 30 Mar 2016 00:06:00 -0400 > Subject: Re: [boost] [filesystem] Horrible documentation > > What sort of documentation unification with other libraries do you mean ? By saying unification, I'm talking about the green-background header. It's in most documentation and also on the homepage. > Can you not increase the font size, if it is too small for you to read, in your preferred browser since the doc is HTML ? The layout is quite problematic. Not only the font, text breaks border, and the page is too tall(long). I noticed it's created with FrontPage 2002. Come on, this is 2016.

3 2

[release] Download data
by Daniel James 31 Mar '16

31 Mar '16

Hi, Currently the download details for a release are included in the quickbook source file for the release notes, which is a bit wonky, and makes it tricky to add extra data, so I'm thinking about storing it separately. This should make it easier to add things like hash signatures and links to third party downloads, such as the windows binaries. So I'm thinking about how to make it easy for people to add the details of their downloads. Could possibly create an extra file for each release, and then people can add data using pull requests, much as we've been using pull requests on the quickbook files, which seems to work fairly well. Another possibility is that we could pull in the details from the server's API, although I don't really fancy having to support multiple data sources with different APIs. Any other ideas? Also, is there any way in which you'd like me to make this kinds of information available for your scripts, packaging etc. Here's a rough version of how the internal data might be stored in a JSON file (other file formats are possible): { 'version': '1.61.0', 'status': 'beta', 'release-notes': '/feed/history/boost_1_61_0.qbk', 'documentation': '/doc/libs/1_61_0/', 'downloads': [ { 'url': 'http://..../boost_1_61_0_beta1.tar.bz2', 'hash': '484c635.....' }, { 'url': 'http://..../boost_1_61_0_beta1.7z', 'hash': 'f93de8.....' }, // ... ], 'third-party': [ { 'url': 'http://...', 'title': 'Windows binaries', 'whatever_else': '' } ] }

1 0

[filesystem] Horrible documentation
by Tatsuyuki Ishi 30 Mar '16

30 Mar '16

Sorry for complaining. Is there any plan to use any documentation tool to regenerate this? It's not unified with other libraries, and too horrible due to the small font size. I really can't read that.

2 1

[Root Pointer] Benchmark w/ Threading = 124% faster
by Phil Bouchard 30 Mar '16

30 Mar '16

I just noticed that if I do not define the BOOST_DISABLE_THREADS macro, root_ptr is faster than allocate_shared_noinit by 124%: unique_ptr (new): 42.1397 unique_ptr (make_unique): 43.4631 shared_ptr (new): 76.4543 shared_ptr (make_shared): 76.6611 shared_ptr (allocate_shared_noinit): 81.9926 root_ptr (new): 66.3417 Thanks, -Phil

1 2

Fwd: [sort parallel] New Parallel Sort Algorithm
by Francisco José Tapia 29 Mar '16

29 Mar '16

This message is for to announce the new version of the Boost Sort Parallel algorithms. You can find in http://github.com/fjtapia/sort_parallel. In the documentation, you can see the description of the algorithms, examples of invocations, and the graphs of the benchmark of the algorithms. The benchmark was not include in the library. I created other repository https://github.com/fjtapia/sort_parallel_benchmark, where you can find the code of the benchmark, the library, and the external code of the TBB parallel stable sort. It was not logic, include external code inside the library. The most significant of this version is the new parallel sort algorithm (internally named Block Indirect Sort) In the Parallel Sort Algorithms, we can find two groups. - Algorithms very fast with many threads (GCC Parallel Sort, Microsoft Parallel Buffered Sort), but use an additional memory as the data. - Algorithms without additional memory, but slower with many threads (TBB Parallel Sort, Microsoft Parallel Sort) The new algorithm *invented, designed and implemented by the author, provide the speed of GCC Parallel Sort and a memory usage similar to TBB. With the additional advantage that don't need any library ( Open MP , TBB, Microsoft PPL …). Only need a C++11 compiler. An example shows you this : Sorting 100 000 000 random numbers of 64 bits. In a server with 32 threads. The results obtained was *Time spent* *Memory used (MB)* *GCC Parallel Sort* 1.05 secs 1560 MB *TBB Parallel Sort* 1.76 secs 783 MB *Block Indirect Sort* 0.97 secs 790 MB In the repository with the benchmark code you can find the benchmark results with several machines https://github.com/fjtapia/sort_parallel_benchmark/tree/master/Linux64_GCC/… <https://github.com/fjtapia/sort_parallel_benchmark/tree/master/Linux64_GCC/…>In these files, you can see the rival is GCC. TBB is clearly surpassed, due to their internal algorithm. GCC divide the data, sorted independently by all the threads. And after for to merge do an easy process, and copy in an auxiliary memory, of the same size than the used by the data. All the threads are fed, but need the double of memory. The new algorithm, do the division, and sort independently, but for the merge, have a small buffer of 1024 elements, and when a part is moved to the buffer, must calculate which part must be copied in that place. Do the same but without the additional memory. Due this, need more CPU for to do the process. The hyper threading (HT) provide around a 30% more power to the processor, and usually in the machines with HT activate, the new algorithm is a bit faster than GCC, and with the HT deactivate is slower, and TBB is slower except when very big objects. But then the bottleneck is not the algorithm, is the data bus The new algorithm is a collection of bad algorithms when you have only 1 thread. But they are easily subdivided. This permit parallelize all the process and have fed all the threads. The new algorithm is documented in two articles - block_indirect_sort_brief_en.*:* (Introduction and graph benchmarks) - block_indirect_sort_en.pdf: (Introduction, detailed description of the algorithm and benchmarks.) If you want to test the benchmark in your machine it's easy. In the benchmark repository, you have the code used, and shell scripts for to compile and run, saving the results in a Results.txt file, for Linux GCC and CLANG and Windows Visual Studio 15 If you see any problem, mistake, something to improve or need any other information, please, say me. Yours Francisco * Invented: The algorithm had been ideate, designed and implemented beginning from zero from an old idea. After read hundreds of articles and books, I didn't find any similar. If you know something, please say me. But the important is not the author, is provide a fast, robust, and easy to use algorithm to the community of programmers.

1 0

[Boost 1.61] Open for bugfixes?
by Louis Dionne 29 Mar '16

29 Mar '16

Hi, On the release calendar [1], it is written that Boost 1.61 is currently open for bug fixes (since March 17). Some previous discussion left me under the impression that authors still had to ask a permission for pushing to their master branches. So, can I push (bugfixes) to Hana's master branch? Do I have to ask the permission when the calendar says it's open? Can I always rely exclusively on the official calendar at [1]? Thank you, Louis Dionne [1]: http://www.boost.org/community/index.html

2 2

[move][sort] Asymptotically optimal stable and in-place merging and sorting with no auxiliary memory
by Ion Gaztañaga 27 Mar '16

27 Mar '16

[Disclaimer, long e-mail, thank you for your attention] Hi to all, Some months ago I tried to gain interest from sorting experts about implementing stable and inplace merge [O(N)] or sort [O(NlongN)] algorithms that don't need additional memory. My main use case for these algorithms was lowering the complexity guarantees of range insertion functions offered by flat associative containers without any temporary allocation (the programmer does not expect allocations when capacity() is big enough to hold the new elements). On the other hand, I wanted those algorithms to be adaptive so as to take advantage of the extra capacity already allocated by flat containers. Of course, if a good implementation is available in Boost, it could be used as existing practice to change the worst-case complexities of some STL algorithms when no additional memory (e.g. get_temporary_buffer()) is available. After reviewing several algorithms from papers and some open source implementations, I decided to implement one of those algorithms. The implemented algorithm is based on the GrailSort algorithm developed by Andrey Astrelin. The main idea of the my adaptive_sort algorithm is explained by Andrey in an article published by the russian collaborative blog Habrahabr (http://habrahabr.ru/post/205290/) The algorithm is based on ideas explained by Huang and Langston in their paper "Fast Stable Merging and Sorting in Constant Extra Space (1989-1992" (http://comjnl.oxfordjournals.org/content/35/6/643.full.pdf) Since the implementation from (https://github.com/Mrrl/GrailSort) is macro-based, does not support non-memcopyable types and has a MIT license (which seems to be problematic for Boost), I implemented the algorithm from scratch following the article and taking ideas from Andrey's implementation. I added some new ideas and optimizations in order to reduce comparisons and elements moves. I must say that the implementation was really hard for someone like me without experience in sorting algorithms, the complexity is huge when compared with a classic mergesort algorithm. The implementation is already in develop and master branches but the develop branch contains more tests and a refactored and more documented code. So please check the code from the develop branch if interested. The implementation is still experimental and not production ready. What about benchmarks? I've only experimented in the oldest Visual compilers to make sure it correctly supports Boost.Move emulation and complexity guarantees were correct. Note that the STL algorithms tested in the benchmark might not be as fast as current implementations. In general, the new algorithms need much more elements moves than algorithms that allocate O(n) memory, but they are still quite fast when data movement is cheap (e.g. when a move constructor just copies a couple of pointers). These are the numbers for A VERY LIGHTWEIGHT object (a struct holding two integers, one for the key, another one to test the stability, don't take times very seriously, just pay attention to the number of comparisons/moves). ////////////////////////// ////////////////////////// STABLE MERGING ////////////////////////// ////////////////////////// - N: number of elements - NK: number of keys (0 means all keys different) - InplaceMerge: std::inplace_merge - Sqrt2AdaptMerge: adaptive_merge with an auxiliary buffer of 2*sqrt(N) elements - SqrtAdaptMerge: adaptive_merge with an auxiliary buffer of sqrt(N) elements - AdaptMerge: adaptive_merge with no external buffer - Cmp: number of comparisons / N - Cpy: number of move constructor/assignments / N - (ratio): time of execution / time needed by InplaceMerge ---------------------------------------------- Numbers produced by the bench_merge.cpp test in Boost.Move: ---------------------------------------------- - - N: 100001, NK: 511 - - InplaceMerge Cmp: 0.9989 Cpy: 1.5000 633.65us ( 1.00) Sqrt2AdaptMerge Cmp: 1.2429 Cpy: 4.4209 910.16us ( 1.44) SqrtAdaptMerge Cmp: 4.2708 Cpy: 5.6712 1.63ms ( 2.57) AdaptMerge Cmp: 5.6014 Cpy: 8.7573 3.11ms ( 4.91) - - N: 100001, NK: 2047 - - InplaceMerge Cmp: 0.9998 Cpy: 1.5000 604.77us ( 1.00) Sqrt2AdaptMerge Cmp: 1.2449 Cpy: 4.4483 934.83us ( 1.55) SqrtAdaptMerge Cmp: 2.0131 Cpy: 4.7609 1.12ms ( 1.85) AdaptMerge Cmp: 2.7608 Cpy: 11.1419 2.83ms ( 4.67) - - N: 100001, NK: 8191 - - InplaceMerge Cmp: 0.9999 Cpy: 1.5000 653.51us ( 1.00) Sqrt2AdaptMerge Cmp: 1.2443 Cpy: 4.3179 943.86us ( 1.44) SqrtAdaptMerge Cmp: 1.4661 Cpy: 4.4348 998.62us ( 1.53) AdaptMerge Cmp: 1.7692 Cpy: 10.6292 2.54ms ( 3.89) - - N: 100001, NK: 32767 - - InplaceMerge Cmp: 1.0000 Cpy: 1.5000 772.06us ( 1.00) Sqrt2AdaptMerge Cmp: 1.2417 Cpy: 4.4317 1.03ms ( 1.33) SqrtAdaptMerge Cmp: 1.3320 Cpy: 4.4758 1.06ms ( 1.38) AdaptMerge Cmp: 1.5295 Cpy: 10.1233 2.44ms ( 3.16) - - N: 100001, NK: 0 - - InplaceMerge Cmp: 1.0000 Cpy: 1.5000 881.88us ( 1.00) Sqrt2AdaptMerge Cmp: 1.2387 Cpy: 4.4124 1.16ms ( 1.31) SqrtAdaptMerge Cmp: 1.2933 Cpy: 4.4412 1.20ms ( 1.36) AdaptMerge Cmp: 1.4110 Cpy: 7.5794 1.93ms ( 2.19) In general, with no memory and enough keys, the algorithm needs 7,5*N data moves and 1,5*N comparisons. Data locality is quite high and with cheap-moving types the overall time can be just two-three times slower. With fewer keys, the algorithm might need upt to 5xN comparisons and 11xN moves. Number are improved if an auxiliary buffer of sqrt(N) elements is available. The number of comparisons and moves are even better than those shown in experimental results from several papers, but I still find them quite high. The algorithm needs some initial steps (e.g. unique key extraction) that are not amortized during the merge (adaptive_sort amortizes the initial steps much better ). I've derived the merge algorithm from the sorting algorithm so maybe there is room for improvement (I've invested much more time in the sorting algorithm). ////////////////////////// ////////////////////////// STABLE SORTING ////////////////////////// ////////////////////////// Numbers when sorting: - N: number of elements - NK: number of keys (0 means all keys different) - MergeSort: A half-copying mergesort (it only needs N/2 auxiliary memory) implemented in boost/move/algo/detail/merge_sort.hpp. Based on the paper "Fast mergesort implementation based on half-copying merge algorithm" by Cezary Juszczak (http://kicia.ift.uni.wroc.pl/algorytmy/mergesortpaper.pdf) Usually faster than std implementations with less auxiliary memory. - StableSort: std::stable_sort - HeapSort: std::heap_sort - QuartAdaptSort: adaptive_sort with N/4 auxiliary memory - Sqrt2AdaptSort: adaptive_sort with 2*sqrt(N) auxiliary memory - SqrtAdaptSort: adaptive_sort with sqrt(N) auxiliary memory - SqrtHAdaptSor: adaptive_sort with sqrt(N)/2 auxiliary memory - AdaptSort: adaptive_sort with no auxiliary memory - Cmp: number of comparisons / N - Cpy: number of move constructor/assignments / N - (ratio): time of execution / time needed by MergeSort [numbers produced by the bench_sort.cpp test in Boost.Move] - - N: 100001, NK: 511 - - MergeSort Cmp: 16.379 Cpy: 16.707 6.49ms ( 1.00) StableSort Cmp: 20.594 Cpy: 22.978 10.85ms ( 1.67) HeapSort Cmp: 16.992 Cpy: 22.098 10.98ms ( 1.69) QuartAdaptSort Cmp: 17.659 Cpy: 26.314 8.34ms ( 1.29) Sqrt2AdaptSort Cmp: 17.829 Cpy: 35.340 9.90ms ( 1.53) SqrtAdaptSort Cmp: 27.805 Cpy: 56.059 19.48ms ( 3.00) SqrtHAdaptSort Cmp: 27.356 Cpy: 60.375 20.35ms ( 3.14) AdaptSort Cmp: 27.352 Cpy: 67.889 21.83ms ( 3.36) - - N: 100001, NK: 8191 - - MergeSort Cmp: 16.394 Cpy: 16.725 7.47ms ( 1.00) StableSort Cmp: 20.578 Cpy: 22.978 11.92ms ( 1.60) HeapSort Cmp: 16.992 Cpy: 22.099 11.91ms ( 1.59) QuartAdaptSort Cmp: 17.676 Cpy: 26.362 9.26ms ( 1.24) Sqrt2AdaptSort Cmp: 17.847 Cpy: 35.747 10.93ms ( 1.46) SqrtAdaptSort Cmp: 18.977 Cpy: 41.641 12.19ms ( 1.63) SqrtHAdaptSort Cmp: 17.076 Cpy: 57.799 15.47ms ( 2.07) AdaptSort Cmp: 17.090 Cpy: 67.179 17.37ms ( 2.33) - - N: 100001, NK: 32767 - - MergeSort Cmp: 16.395 Cpy: 16.727 7.66ms ( 1.00) StableSort Cmp: 20.581 Cpy: 22.986 12.16ms ( 1.59) HeapSort Cmp: 16.994 Cpy: 22.099 11.96ms ( 1.56) QuartAdaptSort Cmp: 17.674 Cpy: 26.319 9.47ms ( 1.24) Sqrt2AdaptSort Cmp: 17.833 Cpy: 35.792 11.16ms ( 1.46) SqrtAdaptSort Cmp: 18.967 Cpy: 41.604 12.42ms ( 1.62) SqrtHAdaptSort Cmp: 17.065 Cpy: 57.756 15.71ms ( 2.05) AdaptSort Cmp: 17.081 Cpy: 67.131 18.32ms ( 2.39) - - N: 100001, NK: 0 - - MergeSort Cmp: 16.399 Cpy: 16.731 7.76ms ( 1.00) StableSort Cmp: 20.521 Cpy: 22.920 12.23ms ( 1.58) HeapSort Cmp: 16.991 Cpy: 22.094 11.85ms ( 1.53) QuartAdaptSort Cmp: 17.671 Cpy: 26.380 9.50ms ( 1.22) Sqrt2AdaptSort Cmp: 17.825 Cpy: 35.653 11.17ms ( 1.44) SqrtAdaptSort Cmp: 18.954 Cpy: 41.545 12.42ms ( 1.60) SqrtHAdaptSort Cmp: 17.058 Cpy: 57.694 15.66ms ( 2.02) AdaptSort Cmp: 17.072 Cpy: 67.072 17.57ms ( 2.26) In general, with no memory and enough keys, the algorithm needs nearly optimal comparisons and significantly more (4x) data movements. Data locality is quite high and with cheap-moving types the overall time can be just two-three times slower. With fewer keys, the algorithm performs worse but it's quite competitive. When extra memory (e.g. sqrt(N)) is available, the algorithm is quite fast with cheap-moving types. //////////////////////////////////////////// Final words: The effort to implement the algorithms was big and I couldn't fix many open bugs in my libraries, so in the following months I don't expect to invest much time on this. At least I wanted to publicly share the committed implementation so that it can be improved by sorting experts. I don't claim these algorithms are groundbreaking or even useful for many programmers, but they might be a good starting point. I'm not happy with the implementation as the algorithm is complicated and I' haven't found a way to simplify it further without noticeable slowdowns. For those interested in the implementation and the algorithm: please contribute correct benchmarks and testing, as there are very few open source implementations of similar algorithms. Any optimization, patch or bug report is welcome. Best, Ion

4 9

Boost 1.61.0 Beta 1 Release Candidate 2
by Vladimir Prus 26 Mar '16

26 Mar '16

Second set of release candidates for 1.61.0 beta 1 are now available: http://boost.cowic.de/rc/boost_1_61_0_b1_rc2.zip http://boost.cowic.de/rc/boost_1_61_0_b1_rc2.tar.bz2 http://boost.cowic.de/rc/boost_1_61_0_b1_rc2.tar.gz http://boost.cowic.de/rc/boost_1_61_0_b1_rc2.7z 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. The changes from RC1 are: * Top-level directory in the archive matches the name * Zip and 7z archives use CRLF line endings The known issues are: * Documentation build has some wrong-location, extra-files and broken-links issues. * There was a report of Boost.Context issue on OSX Release managers believe these issues are not blocking beta 1. The SHA1 checksums are as follows: 4d3c83d3a802d3dd12d4f2d516b3fcf076f6f6ba boost_1_61_0_b1_rc2.7z 8c6ac7326a3cabcabf6c7876052b73e0d41fc36d boost_1_61_0_b1_rc2.tar.bz2 e82b8ff7c3ad5b08c7dbeac1ea85fcf707a1cd4d boost_1_61_0_b1_rc2.tar.gz 7292e8fdac0566fe098a60a197a5722d381842d3 boost_1_61_0_b1_rc2.zip The SHA256 checksums are as follows: bc8341bfb8c6621319ad9eb732179fc7ec4da35c3cefc31b613f83ec3df10361 boost_1_61_0_b1_rc2.7z c0f06c78c195af9079773a2b250674244f1899ec81e84d5455f0761f1d888a16 boost_1_61_0_b1_rc2.tar.bz2 400fa0949aa201d993bf116461365e5d44904a3f8db6412f4f40f2b4ab490405 boost_1_61_0_b1_rc2.tar.gz d75688ecad601303dda2658e9a3d06f406dd4dc8e2c13c36bdadcac0a11dcffa boost_1_61_0_b1_rc2.zip Thanks! -- The release managers

9 15

[Root Pointer] Partial documentation
by Phil Bouchard 26 Mar '16

26 Mar '16

The documentation is not completed yet but an updated overview, a basic tutorial and the rationale are available here: https://htmlpreview.github.io/?https://raw.githubusercontent.com/philippeb8… https://htmlpreview.github.io/?https://raw.githubusercontent.com/philippeb8… https://htmlpreview.github.io/?https://raw.githubusercontent.com/philippeb8… Thanks, -Phil

1 0