November 2016 - Boost - lists.preview.boost.org

[outcome] Requesting pre-review of Boost.Outcome tutorial
by Niall Douglas 24 Nov '16

24 Nov '16

Dear Boost, I am hoping to bring Boost.Outcome, a C++ 14 library providing a factory and family of policy driven lightweight monadic value-or-error transports, into the Boost peer review queue by March 2017 followed shortly thereafter by an ACCU talk in April if my talk proposal passes their programme committee. To that end, I've written an explanation and a sort of tutorial explaining the history and purpose of Outcome at https://ned14.github.io/boost.outcome/ and I'd greatly appreciate if people could tell me: 1. Does it make sense? 2. Do you think you could use Outcome in your own code after reading it? 3. Do you think you would want to use Outcome in your own code after reading it? 4. Are there any missing parts which are showstoppers? My thanks in advance. Be aware the install stuff described at the start doesn't work yet. The reference documentation is also quite patchy thanks to doxygen not understanding CRTP. All that stuff and a fair bit more remains to fix before it's ready to enter the Boost peer review queue. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

6 14

[beast] Separation between parse and generation and asio
by Felipe Magno de Almeida 24 Nov '16

24 Nov '16

Hello, I'm trying Beast with avr-gcc to see how much footprint it would take on embedded applications. Unfortunately, stream_concepts uses asio types, which requires asio include which requires network includes which will obviously fail in most microcontrollers. Would it be possible to make parse and read implementation less dependent on each other? Boost.Spirit x3 works very well on microcontrollers. I'd expect a different type for messages which could actually receive iterator pairs for strings with Beast might give a very good option for HTTP/WS implementation on microcontrollers. Regards, -- Felipe Magno de Almeida

1 0

[sort] Parallel sorting sub-library mini-review conclusion
by Christophe Henry 22 Nov '16

22 Nov '16

> I would like to know the memory used and the best, >normal and worst case of the Asynchronous sorting algorithms. The sort versions are mergesort so they use double memory. The quicksort versions require no extra memory while partitioning. When they degrade after some partitioning iterations, they require the extra memory used by the underlying sort algorithm (spreadsort, std:sort, intro_sort, etc.). Thank you Francisco for this interesting library which I shamelessly used into my own ;-) It's probably a bit late but I vote for acceptance. Cheers, Christophe

2 1

Re: [boost] [sort] Parallel sorting sub-library mini-review. Performance tests.
by Christophe Henry 22 Nov '16

22 Nov '16

>> >> OTOH the single-threaded ones are interesting, especially the stable_sort >> and intro_sort for cases where usage of spreadsort is not possible. >> >I challenge you to find a sorting problem where it isn't possible to use >spreadsort. string_sort can sort anything that std::sort can; > you just need to convert the sort key comparison sequence into a sequence of bytes > and feed string_sort the correct functors. That said, it may not be >efficient to sort some problems with string_sort, >and it'll probably be too much work to be worth the effort for many problems. This is what I meant. Sorry for the lack of precision. I'll add it to my performance tests, it might be an interesting variant as the algorithm is really fast. >> >> A short summary: >> >> 100000000 uint64_t elements already sorted: >> Boost parallel sort : 0.064965 secs >> >> Asynchronous parallel sort : 0.0167134 secs (same with other >> algorithms) >> >> Asynchronous provides a special optimization for this case. >> >If this optimization is practical to incorporate in Boost parallel sort, >it is a common case and your solution seems noticeably faster, >so I would like Francisco to consider it. That said, .06s isn't bad. Sure. >> >> I added this one: >> 100000000 uint64_t elements reverse sorted >> >> Boost parallel sort : 0.581381 secs >> >> Asynchronous parallel sort : 0.0478701 secs >> >> Asynchronous provides a special optimization for this case. >> I this the library should do it too. This one is pretty common and a >> popular DOS attack. >> > This optimization would be nice to have, if it's cheap. A parallel reverse is in O(n) so it's cheap compared to a sort. >> >> 100000000 uint64_t elements randomly filled >> >> Asynchronous parallel quickspreadsort: 0.587432 secs >> Asynchronous quick_intro_sort : 0.728393 secs >> >> This mixing of quicksort degrading into a spreadsort works here best. >I find this algorithm interesting; Frankly, there is nothing special. It's simply a parallel partition, which degrades into a "normal" parallel merge sort (in this case spreadsort) after a while. >have you considered using MSD radix-based sorting to break up the data > for the threads in parallel? >For example, take T threads, have each thread take 1/T of the data > and bucket it into N MSD-based buckets (just like Spreadsort), >where T < N <= ~2^11, then merge the equivalent buckets, >and as you merge them hand them off to another thread to sort. >This will probably divide better if you find the max and min before bucketing >using a parallel min/max search. I admit I didn't. But it sounds really interesting and I think I'll have a go at it. I'm not a sort expert though. I approached this from the parallel perspective. >> 10000000 strings randomly filled >> >> OMP parallel sort : 1.05803 secs >> Boost parallel sort : 0.933055 secs >> >> OMP parallel stable sort : 1.12269 secs >> Boost sample sort : 0.889216 secs >> Boost parallel stable sort : 1.56564 secs >> >> Asynchronous parallel quickspreadsort: 0.788856 secs >> Asynchronous quick_intro_sort : 0.893652 secs >> >> Asynchronous parallel stable sort : 1.23495 secs >> Asynchronous boost::stable sort : 1.21817 secs >> >> Similar results. >> >> >> Let's move on to big objects: >> >> 1562500 elements of size 512 randomly filled >> H E A V Y C O M P A R I S O N >> >> OMP parallel sort : 0.308923 secs >> Boost parallel sort : 0.342992 secs >> >> Asynchronous parallel_quicksort : 0.246709 secs >> Asynchronous quick_intro_sort : 0.269666 secs >> >> Both quicksorts are best, with a slight advantage to intro_sort. >> >> The light comparison is similar. >> >Do we have your permission to copy and/or adapt your quick_intro_sort >algorithm into the Boost.Sort library? Please feel free to copy whatever might be useful. The library has a Boost license as it's intended for inclusion in Boost.I also took the freedom of adding the single-thread versions of Fernando's algorithms as basis for my parallel versions. The algorithm is quite simple. It's the same as quick_spreadsort, a quicksort which degrades into Francisco's intro_sort after some iterations. I just found it interesting to add a wrapper to Francisco's algorithm for the mini-review. It was just a quick test (no time for cleverer algorithms) but I'm pretty satisfied with the result and I'll keep these versions. >How is the worst-case performance relative to Francisco's library? The sort versions have O(n log n) like any merge sort. The quicksort have O(n log n) to O(n^2) as expected from a quicksort. Cheers, Christophe

1 0

Re: [boost] [sort] Parallel sorting sub-library mini-review. Performance tests.
by Christophe Henry 22 Nov '16

22 Nov '16

Hi, > The threads are created only 1 time*. Have I missed something? I checked sample_sort and I saw several sets of calls to std::async which is likely to create and destroy threads several times. >*parallel_sort, sample_sort* : this algorithm is commonly accepted as the >fastest for the parallel stable sort. >The implementation is *notoriously faster than the provided by the GCC compiler* >( based on Open MP ) using less memory. TBB don?t >provide parallel stable sort, and only have an experimental code in their web pages Indeed, I found it highly interesting. Cheers, Christophe

1 0

[release] Boost 1.63.0 - fixes
by Oliver Kowalke 22 Nov '16

22 Nov '16

unfortunately beta 1 does not contain fixes from boost.context and boost.fiber. could you add the fixes to the 1.63 release, please? Oliver

3 4

[sort] Parallel sorting sub-library mini-review starts tomorrow, 11 November
by Steven Ross 22 Nov '16

22 Nov '16

Dear Boost community, The mini-review of Francisco Tapia's Parallel sorting library begins tomorrow November 11, and ends November 20th. The purpose of this review is to assess whether the sub-library is useful and up to Boost software standards. If the Boost community agrees on both, Francisco and I will integrate it into the existing Boost.sort library as a separate sub-library from Spreadsort. In doing so we'll integrate the documentation with the existing documentation for Boost.Sort, making it more consistent. If you review Francisco's library, please make sure you're using a compiler that supports C++11, and answer each of these questions: 1. Were you able to run it and see accurate and fast results? Please specify your compiler, OS, and processor type, and any problems (or slowdowns) encountered. 2. Would you use this library if accepted? Why or why not? 3. What is your evaluation of the design? 4. What is your evaluation of the implementation? 5. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? The library is here: https://github.com/fjtapia/sort_parallel This library provides both stable and unstable sorting algorithms, in single threaded and parallel versions. - All the algorithms have average and worst case runtime of O(NLogN). - These algorithms do not use any other library or utility. To compile and run these you will need a *C++11 compliant compiler.* - *This library is *include only, only requiring* the files in the boost/sort/parallel folder, with no external dependencies.* - The algorithms use a comparison object, in the same fashion as std::sort, defaulting to the std::less object, which uses the < operator internally for comparisons. - The algorithms are exception safe, meaning that the exceptions generated by the algorithms guarantee the integrity of the objects to sort, but not their relative order. If the exception is generated inside the objects (in the move or in the copy constructor) the results can be unpredictable. The library has a a new parallel_sort algorithm *( internally named Block Indirect)*, for processors connected with shared memory*,* invented for the library. This new algorithm combines the speed of algorithms like the GCC parallel sort (based on OpenMP), or the Microsoft parallel buffered sort, with the small memory consumption of algorithms like the TBB sort and the Microsoft parallel Sort. Results from running on an I7 5820 with 12 threads: GCC parallel_sort 1,25 secs 1560 MB TBB parallel_sort 1,64 secs 783 MB Boost parallel_sort 1,08 secs 786 MB In a separate repository (because it uses licence-restricted software like TBB and Microsoft parallel sort, and can’t be included in the Boost library), you can find all the code needed to run the benchmarks, the library code, the benchmark programs, and shell scripts to compile and run it on your machine in Linux and Windows. For the Linux benchmarks you will need to install TBB. (https://github.com/fjtapia/sort_parallel_benchmark) We look forward to your feedback!

4 5

Re: [boost] [sort] Parallel sorting sub-library mini-review. Performance tests.
by Christophe Henry 22 Nov '16

22 Nov '16

Hi Boost Community, I did not manage yet to write a full review. One week is a bit short so a few more days will be necessary. I provide some performance tests first. To check the library performance, I pitted it against my own versions of a parallel mergesort and quicksort provided by the asynchronous library ( https://github.com/henry-ch/asynchronous) which is now ready for review, so we have a stable state for testing. I also added a parallel version inside the asynchronous library using Francisco's single-thread implementations to compare with his parallel ones. I tested on a i7-5960X. Due to time limits, I could not test on more interesting NUMA platforms (I did not get the reviewed library to compile for my KNC) so the tests do not pretend to have value outside the i7 architecture. I linked with tbb_malloc_proxy to limit memory influence. In a nutshell. I'm not a big fan of the parallel version of the algorithms. It seems to be based on std::async, so that a lot of threads are started and joined at every call. I would suggest using a threadpool. OTOH the single-threaded ones are interesting, especially the stable_sort and intro_sort for cases where usage of spreadsort is not possible. Cheers, Christophe A short summary: 100000000 uint64_t elements already sorted: OMP parallel sort : 0.390899 secs Boost parallel sort : 0.064965 secs OMP parallel stable sort : 1.06128 secs Boost sample sort : 0.0695357 secs Boost parallel stable sort : 0.0662401 secs Asynchronous parallel sort : 0.0167134 secs (same with other algorithms) Asynchronous provides a special optimization for this case. I added this one: 100000000 uint64_t elements reverse sorted OMP parallel sort : 0.317039 secs Boost parallel sort : 0.581381 secs OMP parallel stable sort : 1.06448 secs Boost sample sort : 0.524746 secs Boost parallel stable sort : 0.73036 secs Asynchronous parallel sort : 0.0478701 secs Asynchronous provides a special optimization for this case. I this the library should do it too. This one is pretty common and a popular DOS attack. 100000000 uint64_t elements randomly filled OMP parallel sort : 1.03594 secs Boost parallel sort : 0.796447 secs OMP parallel stable sort : 1.28601 secs Boost sample sort : 0.818954 secs Boost parallel stable sort : 1.13604 secs Asynchronous parallel quickspreadsort: 0.587432 secs Asynchronous quick_intro_sort : 0.728393 secs This mixing of quicksort degrading into a spreadsort works here best. The parallel adaptation of intro_sort is not bad either and best of other library algorithms. Asynchronous parallel stable sort : 1.26141 secs Asynchronous boost::stable sort : 0.804814 secs Interesting. The stable version of the library easily beats std::stable_sort I used until now. 10000000 strings randomly filled OMP parallel sort : 1.05803 secs Boost parallel sort : 0.933055 secs OMP parallel stable sort : 1.12269 secs Boost sample sort : 0.889216 secs Boost parallel stable sort : 1.56564 secs Asynchronous parallel quickspreadsort: 0.788856 secs Asynchronous quick_intro_sort : 0.893652 secs Asynchronous parallel stable sort : 1.23495 secs Asynchronous boost::stable sort : 1.21817 secs Similar results. Let's move on to big objects: 1562500 elements of size 512 randomly filled H E A V Y C O M P A R I S O N OMP parallel sort : 0.308923 secs Boost parallel sort : 0.342992 secs Asynchronous parallel_quicksort : 0.246709 secs Asynchronous quick_intro_sort : 0.269666 secs Both quicksorts are best, with a slight advantage to intro_sort. The light comparison is similar. My test code (the modified benchmark.cpp provided by the library): https://github.com/henry-ch/asynchronous/blob/master/libs/asynchronous/test… The full test results: https://github.com/henry-ch/asynchronous/blob/master/libs/asynchronous/test…

3 2

[process] daemon ideas
by Dracon Pern 21 Nov '16

21 Nov '16

I am not sure if [process] is the right library, but I am thinking about building something to manage daemon install/uninstall across platforms, for example Windows's service, OS X's launchd, systemd, and SysV init. Every operating system offers some way to launch a daemon at boot, and also the ability to stop, recover, etc. The issue is they all do it slightly differently, unlike having a common main(). My thinking is to provide a thin layer for install/remove and service notification. I have looked at Boost.Application, but it's lacking install/uninstall, and also seems overly complicated. Thoughts? Thanks, -Eric

4 3

Re: [boost] [iterator] Orbiting iterators
by Jeremy Murphy 20 Nov '16

20 Nov '16

Hi Steve, On 21 Nov 2016 3:01 AM, "Steve M. Robbins" <steve(a)sumost.ca> wrote: > > On Sunday, November 20, 2016 8:25:20 PM CST Jeremy Murphy wrote: > > Hi, > > > > just wondering what the mood in Boost.Iterator is for new features? At work > > we recently found use for an orbiting iterator, specifically a circular > > one, which effectively wraps at the start/end of a bounded range. (The > > domain is digital signal processing.) > > That sounds like what CGAL calls a Circulator; c.f. http://doc.cgal.org/ > latest/Circulator/classCirculator.html Right, yeah. Unfortunately I can't view the documentation properly on my phone so I'll take a look later, but I imagine the principle is the same although the interface is not. > > Implementation details aside, does this feature sound desirable to the > > library? > > I've found these handy when iterating through graph edges incident on a > vertex, when you need to start on a specific edge. It's been ages since I've > used them so I can't recall the exact use case. Makes me wonder whether > something like this already exists in boost graph. As you pointed out with CGAL, domain-specific implementations do exist. Boost.Geometry has something too. I guess I'm interested in whether this need for circular iteration can be abstracted back to the plain old iterator. Cheers. Jeremy

1 0