May 2013 - Boost - lists.preview.boost.org

Re: [boost] [GSOC] Are we going to participate?
by Stefan Seefeld 02 May '13

02 May '13

Hi Boris, I just noticed today someone inquiring about Boost.XML as a GSoC project. Being the one who originally suggested that idea almost ten (!) years ago (and who then also implemented a simple sandbox project as a proof-of-concept), I would love to see such a project being successful. Do you think it's still time to work on a proposal ? Where should I register to be an eligible mentor with boost.org ? (I'm already registered with GSoC - my ID is 'stefan'.) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

2 2

[Log] Plans to use std::thread?
by Rich E 01 May '13

01 May '13

Hi all, As I've been testing out the newly added Boost.Log library, I noticed it is relying on Boost.Thread even when the C++11 <thread> library is present. Are there any plans to allow the native <thread> library to be used when it is available? I think this can be done with Boost.Config's BOOST_NO_CXX11_HDR_THREAD macro. Thanks, Rich

2 2

Re: [boost] GSoC Boost.Multiprecision project
by Jyotesh Choudhari 01 May '13

01 May '13

Hello, > Hi Jyotesh. >>>> Looking at the project description, I think >>>> I have understood what needs to be implemented >>>> in this project. > Yes, you seem to have a good grasp of the issues. > Good work. >>>> I have also gone through the current >>>> code cpp_bin_float.hpp and I have understood some >>>> part of it. I want to know how >>>> detailed should my proposal be? What details >>>> should I include in my proposal? >>>> What should be the deliverables for the project? > Go ahead and add some details from cpp_bin_float > if you like. You can mention that this is a potential > solution method. Thank you for your valuable feedback. I have written project proposal for the first time in my life. So, I did not know what details to include. I have made some changes to my proposal as per your suggestions. > Other than that, I believe you have found > the right level of detail, with a few more suggestions > from my side below. >> I have attached my proposal with this mail. >> Please have a look at it and let me know your feedback. >> Thanks and regards, > I suggest you move the FFT algorithms to an optional > part, add a bit more time for the elementary transcendental > functions, and add some time for testing the various > milestones in the project. > After that, you should start submitting your proposal. > As far as I know, you can modify your proposal up > to May 03. I have written FFT algorithm as an optional algorithm now and made some changes to schedule. Please let me know if it is fine now. > Keep up the good work. > Sincerely, Chris I was studying the code for cpp_bin_float and I have some doubts in my mind. 1. What are eval_ops_signed_type, eval_ops_unsigned_type and eval_ops_float_type? 2. What is the use of following lines? typedef mpl::list<eval_ops_signed_type> signed_types; typedef mpl::list<eval_ops_unsigned_type> unsigned_types; typedef mpl::list<eval_ops_float_type> float_types; These are not used in the class elsewhere. Similar lines are present in cpp_dec_float.hpp also and not used elsewhere in the class. 3. In the function from_float_type, I think the variable number_of_digits should be initialized to zero before using it in while loop. Lastly, I have seen on mailing list, that some of the students are submitting code samples. As I am busy with my end-semester exams and R&D project, I am not able to send any sample code. As soon as I get free, I will send it. Thanks and regards, Jyotesh Choudhari

2 1

[gsoc-13][proposal] Boost.uBLAS
by Aditya Avinash 01 May '13

01 May '13

Hi, I have a proposal for boost in gsoc-13 under boost.ublas *Proposal: SIMD abstraction for uBlas.* - I want to develop SIMD abstraction for uBlas. Goal 1: Develop the Intel SSE & AVX backend for SIMD abstraction in uBLAS. Goal 2: Develop AMD SSE backend for SIMD abstraction in uBLAS. Goal 3: Develop frontend for SIMD abstraction in C++. Goal 4: Joining of frontend and backend, so the the code is flexible to implement on both AMD and INTEL. Goal 5: Develop the ARM-NEON backend for SIMD abstraction in uBLAS. (if time permits). -- ---------------- Atluri Aditya Avinash, India.

2 3

Re: [boost] [gsoc-2013] Boost.Thread/ThreadPool project
by Niall Douglas 01 May '13

01 May '13

> Le 29/04/13 21:35, Niall Douglas a ?crit : > > No major changes to the C++11 futures API is needed. Rather that a > > different, but compatible, optimized implementation of future<> gets > > returned when used from a central asynchronous dispatcher. So the C++ > > standard remains in force, only the underlying implementation is more > > optimal. > > Could you explain me what a central asynchronous dispatcher is? An asynchronous procedure call implementation. Here's Microsoft's: http://msdn.microsoft.com/en-us/library/windows/desktop/ms681951(v=vs.85).as px. Here's QNX's: http://www.qnx.com/developers/articles/article_870_1.html. Boost.ASIO is the same thing for Boost and C++ but implemented by application code. It is *not* like asynchronous POSIX signals which are a nearly useless subset of APCs. > If not, please could you elaborate what kind of optimizations can be > obtained? If you have transactional memory in particular, you gain multi-CAS and the ability to (un)lock large ranges of CAS locks atomically, and a central dispatcher design can create batch lists of threading primitive operations and execute the batch at once as a transaction. Without TM, you really need the kernel to provide a batch syscall for threading primitives to see large performance gains. > > Futures come in because you'd naturally use std::packaged_task<> with > > Boost.ASIO. It returns a future. > Could you point me to the Networking paper proposal that has > packaged_task<> on its user interface. I would expect this to be an > implementation detail. You misunderstand me. *If* you want Boost.ASIO to dispatch unknown std::function<>, *then* std::packaged_task<> is the most obvious route forwards. And the correct way to pass a value from one execution context to another is std::future<>. This includes the single threaded case e.g. when going through a C++ -> C -> C++ transition as a stack unwinds. > > For reference, the AFSIO/AFIO project is *not* a threadpool. It's a batch > > asynchronous execution engine based on Boost.ASIO that lets you chain, in > > vast numbers, huge arrays of std::function<> whose returns are fetched using > > std::future<> to be executed asynchronously according to specified > > dependencies e.g. if A and B and C, then D, then E-G. That sort of thing. > So the thread pool you need is an internal one that is adapted to you > particular needs, isn't it? I think you don't understand what Boost.ASIO is or how it works. Boost.ASIO's core is boost::asio::io_service. That is its dispatcher implementation which each dispatch execution context being executed via boost::asio::io_service::run() which is effectively an event loop. Third parties then enqueue items to be dispatched using boost::asio::io_service::post(). You don't have to run Boost.ASIO using multiple threads: it can be single threaded. So is my thread pool an internal one adapted to my particular needs? In the sense I need not use threads at all, yes. In the sense that boost::asio::io_service's use scenario is inviolate, no. Boost.ASIO has its API, and you have to use it. And Boost.ASIO's API will be similar to the TR2 networking API. There is nothing stopping a person merging a Boost.ASIO managed thread pool with a traditional thread pool. I would struggle to see the use case though - this would an excellent thought project actually which would benefit any Boost.ThreadPool. > > One thing presently implemented on that engine is asynchronous file i/o, but > > in the next month or two you'll hopefully see batch parallel SHA256 using > > 4-SHA256 SSE2 and NEON implementations also added to the asynchronous > > engine. The idea is that the engine is fairly generic for anywhere where you > > do need to chain lots of coroutine type items together (not that it supports > > Boost.Coroutine yet). v1 isn't particularly generic nor optimal, but I'm > > hoping with feedback from Boost that v2 in a few years' time would be much > > improved. > > > As Oliver noted you could take a look at Boost.Fiber and Boost.Task. Right now anything Boost.Context based can't have multiple contexts simultaneously entering the kernel apart from on QNX and possibly Hurd. Therefore, for the time being, full fat threads are the only thing being considered. If kernel support ever includes coroutines or fibres, that will be eagerly added (I like coroutines, I use them a lot on Python). Note that on async i/o capable platforms multiple threads are solely used for non-async APIs like batch directory creation and batch chmod. Normal i/o gets multiplexed using completion handlers. Currently on Windows for example, threads are barely used at all. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

3 2

Re: [boost] [operators] moving forward use return by reference for compilers with proper support?
by Andrew Ho 01 May '13

01 May '13

> They do NOT apply to this scenario: > > X&& func(X&& x) { return std::move(x); } > const X& r3 = func(temporary()); // DANGLING REFERENCE > X&& r4 = func(temporary()); // DANGLING REFERENCE Hmm, I see. sub-clause of 12.2 clause 5: > The lifetime of a temporary bound to the returned value in a function return statement (6.6.3) is not extended; the temporary is destroyed at the end of the full-expression in the return statement. I presume there must be some implementation detail on why a returned temporaries' lifetime can't be extended. Too bad, looks like return by value is the best option available.

1 0

[operators] moving forward use return by reference for compilers with proper support?
by Andrew Ho 01 May '13

01 May '13

Following some feedback I got from MS about the disparity between VS2012 and GCC/Clang in how some the lifetimes of temporaries are handled, it appears that going forward (possibly C++14) overloading operators in the same fashion as Dfrey operators should be safe. For reference, these overloads for a single argument commutative operator are: T operator OP(const T&, const T&); T&& operator OP( T&& lhs, const T& rhs); T&& operator OP( const T& lhs, T&& rhs); T&& operator OP( T&& lhs, T&& rhs); They referred me to http://www.open- std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf (draft of C++ standard), which in section 12.2, clause 5 says that a temporary's lifetime is extended to the lifetime of the reference it is bound to. I checked draft n3376 (latest publicly available draft as of today), and the same clause was present. This is the current behavior in VS2012 and it's likely that future compilers will support this as well. Should we start tracking which compilers do exhibit this behavior in Boost.Config and use the return by rvalue ref code if proper compiler support is available? I know these are just working drafts and can change in the future, but I can't think of a reason why they would remove this clause from the C++14 standard, or of any test cases which would cause a program to fail assuming this clause is properly implemented. We'll have to provide an implementation which supports return by value as well for compilers which don't support this clause, and possibly a third implementation for compilers which don't support move semantics at all, though I have demonstrated that Boost.Move can be used to merge these latter cases.

2 1