December 2015 - Boost - lists.preview.boost.org

interest in an asynchronous linear algebra library?
by Oswin Krause 07 Dec '15

07 Dec '15

Hi list, Disclaimer: What I am proposing here does not exist (yet). But it will in the near future and if there is interest i would like to give something back to the boost community. I would like to propose a new library to boost: asynchronous blas. What is it and what can I do with it? It is a linear algebra library where all computations are carried out in an asynchronous manner on GPU and CPU. Computing a matrix-matrix product does not block the current thread but instead launches a task which at some point returns with a result, allowing the main thread to continue until the result is needed. GPU and CPU tasks can be started at the same time depending on each other (e.g. a CPU computation waits until the GPU returned some needed result and vice-versa) Why is this important? Which problems does it solve? Many linear algebra libraries are target towards either a) solving a few large linear algebra problems b) solving many small similar problems This library is targeted towards the middle ground: a medium amount of decently sized problems. Here the problem is that it is often hard to use all the computing resources available as a single problem will not exhaust the device resources and there is no easy way to launch several similar tasks in parallel. This problem occurs often in GPU computing where out-of-order execution of kernels is used to fill up the device. Similarly, it is often hard to make CPU and GPU work together as GPU tasks are asynchronous while CPU tasks are often synchronous and it is not straight forward to couple both without blocking either CPU or GPU. How does it work? Expression templates similar to boost::ublas are used to create a dependency graph: which object is used in which computations and which tasks have to wait to ensure a correct outcome? a simple case would be two independent computations like matrix A=prod(B,trans(B)); matrix C=prod(trans(B),B); a normal library like ublas would wait until A is computed before C is evaluated. Instead, it can be more efficient to just add the two tasks to a list and let worker threads execute them as soon as resources are available. First the computation of A is put into the graph and A is marked as "being written to" while B is marked as "being read". When C is added to the list, it does not depend on the first computation as several tasks can read from B at the same time. So another worker thread can grab the task and execute it. If we now add the task B += prod(D,prod(C,trans(D)); the library computes it as matrix temp = prod(C,trans(D); B += prod(D,temp). temp can be computed as soon as C is computed. But B can only be computed after A and temp are computed as we can only write to B after all previous tasks using B are finished. Are you qualified? I am main contributor to https://github.com/Shark-ML/Shark/ and as part of it I forked ublas https://github.com/Shark-ML/Shark/tree/master/include/shark/LinAlg/BLAS which now uses several linear algebra libraries as possible backends (ATLAS, openBLAS...). What is the timeline? I would start developing a minimal example ASAP based on the rewrite of ublas above. I would use a minimum set of features (only dense square matrices) and basic GPU support. Opinions? Best, Oswin

8 17

[asio] Any interest in a boost::asio::mockup_serial_port ?
by Damien Buhl 07 Dec '15

07 Dec '15

Dear Boost.Asio developers, I wanted to know if there was any interest for a mockup_serial_port_service, so that one might write cross platform unit-tests of code based on serial_port. I implemented this mockup this summer for a project where the best way to unit test some modules was to act as another peer on a serial port and needed to be doable on any platform supported by asio::serial_port. I find it quite useful, because there - is no need to use separate tools like socat on linux or install virtual COM ports applications on windows. Which ease the setup of the test environment - the fake serial port doesn't pollute the system where the test is run - many test cases can be run in parallel, as there is no native ressources involved. One might use it as this : > using namespace boost::asio; > > boost::thread simulate_writing_device([](){ > io_service ios; > basic_serial_port<mockup_serial_port_service> port{ios, "my_fake_serial_port"}; > > const std::string message = "Hello"; > > for (;;) { > boost::asio::write(port, buffer(message.data(), message.size())); > boost::this_thread::sleep_for(boost::chrono::seconds(1)); > } > > }); > > boost::thread simulate_reading_device([](){ > io_service ios; > basic_serial_port<mockup_serial_port_service> port{ios, "my_fake_serial_port"}; > > for (;;) { > char message[5]; > boost::asio::read(port, buffer(message, 5)); > std::cout << "received : " << std::string(message, 5) << std::endl; > } > > }); A short documentation is available here : http://goo.gl/24JnUg And the implementation is on github in a holdall library for the moment : https://goo.gl/E7KGdn It's a library whose goal is to shrink over the time as they get merged in upstreams project. Hopefully there is interest for this mockup_serial_port, and if so I'll cleanup the code some more and make a pull-request to Boost.Asio. Cheers from Berlin where meetingcpp already ended :'-( -- Damien Buhl

2 2

[fiber] ready for next review
by Oliver Kowalke 06 Dec '15

06 Dec '15

As request, I'd like to announce that boost.fiber has addressed the requests of the last review. Especially migrating fibers between threads is supported - sub-directory 'examples' contains code demonstrating work-sharing and work-stealing. boost.fiber: github.com/olk/boost-fiber/tree/develop (branch develop) requires boost.context (branch develop) Oliver

2 22

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

04 Dec '15

Release candidate files for 1.60.0 beta 1 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 rc1: * Boost.Sprit has been updated and Boost.Log now builds. * Boost.Math has been updated and now builds. Known issues: * Errors when building libraries for visual studio: test and type_erasure. * Boost.Test fails when building on Darwin with gcc 4.9.2 The files (and associated md5s) are: MD5 (boost_1_60_0_b1_rc2.7z) = dd38daa9378a6002fc12da0cab695511 MD5 (boost_1_60_0_b1_rc2.tar.bz2) = f3c9ffc14db3b2e55c7c5c703e69883d MD5 (boost_1_60_0_b1_rc2.tar.gz) = 89365262443cc16990b69f8e4b8b47ab MD5 (boost_1_60_0_b1_rc2.zip) = 3389bd4595a989fe95966440cbe45ca9 Thanks! -- The release managers

7 12

thread_specific crashes the application when it is in a .so file
by George Georgiev 03 Dec '15

03 Dec '15

Hi, Is there a known issue about boost::thread_specific when a global thread_specific object is in a .so file? The exact same code replacing it with thread_local boost::unique_ptr<Foo> works. By the way is there a macro that determines is thread_local supported from the compiler or not? Thanks, George

3 3

Documentation for boostbook
by Soul Studios 02 Dec '15

02 Dec '15

I've seen the existing documentation, and wasn't impressed- is there a better site for details on this? Something with at minimum, a copy of the DTD and an example .xml file? Thanks, Matt

1 0