- Boost - lists.preview.boost.org

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

26 Apr '13

> > I'm not ruling out the merit of a Boost.Thread threadpool. For me personally > > though, the hurdle is very significantly raised: you need to strongly prove > > to me why your proposed thread pool is much superior to a Boost.ASIO based > > threadpool. Otherwise I will zero score the GSoC proposal, because in the > > end we need other proposed projects more. > > Superior in what way? Performance-wise, interface-wise? What advanced > features would you want from a thread pool to make it superior to the > presented implementation? That's for the applicant to decide. Any proposal needs to be very significantly better than something based on existing features to pass muster not just with Boost, but with Google themselves. There is always an assumption against duplication of existing functionality just for the sake of it. Niall

1 0

[type_erasure] error in type-erased iterators
by Adam Wulkiewicz 26 Apr '13

26 Apr '13

Hi, iterator< ::boost::no_traversal_tag, ...> defines constructible<T()> requirement. This however musn't be meet in the case of incrementable and single-pass iterators. It should probably be moved to the iterator< ::boost::forward_traversal_tag, ...> Patch attached. Regards, Adam Wulkiewicz

1 0

Fwd: [gsoc 2013] boost.multiprecision
by Sagar Massand 26 Apr '13

26 Apr '13

Hi, I wanted to submit a proposal but I am not sure right now if I am going in the right direction.It would be great if you could guide me here. I was thinking of implementing karatsuba multiplication in the initial stages, complete with a testing of the implementation, and then move on to Schonhage-Strassen and other fast-fourier transform algorithms in the last one and half months seeing that our primary requirement is for numbers uptil 1000 digits. I was also thinking of the implementation of some other division algorithms like Goldschmidt, Newton-Raphson etc. A complete link to my proposal can be found below: https://docs.google.com/file/d/0B5iapFjtoO7GTVR2eGhJd2dXZHM/edit It would be great if you could give suggestions to improve this.Thanks. Regards, Sagar Massand

1 0

[gsoc-2013] Boost.Thread/ThreadPool project
by Dan Lincan 26 Apr '13

26 Apr '13

Hello, My name is Dan Lincan. I'm a 4th year undergratuate student in Computer Science at the "Politehnica" University of Bucharest and I'm interested in the project "Boost.Thread/ThreadPool". I have studied the documents provided as resouces and I would really appreciate if you helped me better understand this project. Are there any tasks that are meant to get solved for the proposal? How do I start? I am aware that it will not be an easy task at all, especially because I don't have much experience with boost, but I'm willing to learn and work as much as it is needed to get it done. Thank you for your time, Dan Lincan

3 15

[Runtime Parameters Reference]Command Line Argument
by Hemanth Choudary M V (RBEI/ETA1) 26 Apr '13

26 Apr '13

Hi, I would like to run selected test cases from multiple tests suits. Pl let me know the command line argument to be passed. Mit freundlichen Grüßen / Best Regards, Hemanth Choudary MV RBEI/ETA1

1 0

Re: [boost] Live read-only GIT mirrors of Boost trunk SVN
by Niall Douglas 25 Apr '13

25 Apr '13

> >The live GIT mirrors of Boost trunk SVN have become a bit stale in recent > >months [...] > > I tried making a mercurial mirror of the Boost trunk SVN and found > that it took so long to do the conversion process, that I could never > get it to complete on my home computer with cable modem internet > access, but I could get it to complete on a shell account with faster > trunk access. I simply allocated an OpenVZ container on my cloud with 64Mb of RAM and 128Mb of swap. > I also found the resulting repository was *huge* because I had *every* > revision of boost ever recorded in the svn repository. Github reckons the entire mirror consumes 700.40Mb. No idea if that's good or bad. > I'm curious if you had different experiences when making a git > repository. To be honest, the process was very straightforward. I configured it as per subgit's instructions. I set it running. It OOMed a few times, but hardly unsurprising with 64Mb of RAM for the VM. I simply restarted when it did. And after a day or two it completed (note that the cloud hardware is a 2Ghz Core 2 without SSD). Better hardware would be far faster. > I am more familiar with mercurial than git, and I wanted to make a > local mercurial repository so that I could work on my changes locally > and checkpoint them using the version control system instead of manual > backups. AFAIK, there's no way to record local changes with > versioning using subversion, there's only committing to the remote > server. Ah, getting subversion commits to match git commits that's subgit's problem :). Subgit gives you three sync options, "safe", "somewhat safe" and "not safe". "safe" locks both subversion and git repos during the sync, however long that takes, and during which no pushes nor pulls nor checkouts may happen. So long as you can live with that (I can), the live two way mirroring works well, but it could be frustrating for users of busy repos. Niall

2 1

Re: [boost] [operators] The future of Boost.Operators
by Andrew Ho 25 Apr '13

25 Apr '13

> Maybe we're talking past each other. I have 3 overload set variants in > mind: > > (A) > T operator?(T, T); > > (B) > T operator?(T const &, T const &); > ... > T operator?(T&&, T&&); > > (C) > T operator?(T const &, T const &); > ... > T&& operator?(T&&, T&&); > > AFAICT, neither (A) nor (B) have any safety issues. Oh, but now I see the > problem with (C): T&&'s are implicitly convertible to T&'s...that's what I > was missing before. Sorry for being dense. > > So if you do > > T& a = b + c; > This succeeds in VS2012 with all (no compile or runtime problems, oddly VS2012 extends the lifetime of ref returned by C to be valid), and fails with all in gcc 4.7.2 (compiler error) :P > invalid initialization of non-const reference of type 'T&' from type 'T&&' Yep, this is what happens in gcc for me. > > I swear I just tried a T& y = static_cast<T&&>(x) on gcc and finding it > compiled fine. This gave a compiler error for me. > Now you can ask the same question with T const& instead... Compile succeeds, with only two operands the called overload returns a T, not T&& so there's no problems. If you had: const T& r = a + b + c; (A) and (B) are perfectly safe, but (C) will have runtime issues. Same goes for: T&& a = b + c; T&& r = a + b + c; First line doesn't have any problems with (A), (B), or (C) because of which overload is used. The second line (A) and (B) have no problems but (C) will have runtime issues. Of course, (C) will have a few extra temporaries created (which may or may not be optimized away). The question originally posed is do we: 1. Ignore this problem with (C) to get better performance and just document the problem? 2. Implement (B) to take advantage of move semantics with no internal problems, albeit with a few temporaries being created (if they aren't optimized away by the compiler)? 3. Implement a user-accessible macro switch to let the user decide globally As Jeff said, (3) is ugly especially when linking different codes together, but does provide the most options to the user. (2) isn't necessarily the most efficient but is completely safe. It may also end up being just as efficient as (1) if compilers support the optimization to remove unnecessary temporaries. Daniel's argument is that the problems which occur with (C) are typically a result of user error, and (C) in general guarantees the least amount of temporaries being used. Are there any cases where the problems described above with (C) would be a result of intended behavior with no acceptable work-around? Hopefully we're on the same page now.

1 0

Google Summer of Code Proposal Feedback
by Niall Douglas 25 Apr '13

25 Apr '13

> aware of GSOC until recently. I had strongly considered writing a proposal > for Boos.ASIO, but I fear my lack of experience with Linux, POSIX, and > concurrency in general might prove to be too great of an obstacle. If the > subject matter can be learned relatively quickly, I would love to discuss > what such a project would require with the mentor, Niall Douglas, or a > community member who has is familiar with the project. I'm hardly "the" mentor in Boost.ASIO. I'm probably just the only one to have registered as a potential mentor so far. It's still early days. A lot more potential mentors will register in time, then depending on project scoring and people's availability and of course Google's preferences, we'll see what turns out. > My original proposal probably isn't unique, and much to my chagrin as I > read the hints for successful proposals it seems a popular topic. I am of > course suggesting a project dealing with Trees. Rather than suggest > building a generic tree, I am suggesting the start of a tree library, or > the addition of several types of trees to existing libraries, as I am not > sure which is more appropriate. An awful lot of students expose their ignorance of what Boost, or indeed the C++ standard library, provides during GSoC. It really doesn't help them to be scored well which is why Boost strongly recommends that students discuss their ideas here first before submission. 95% of the time their idea is already implemented. For example, there are multiple tree implementations in the C++ STL and Boost. Look into Boost.Intrusive for example. > Because trees are such a fundamental data type in computer science, I have > found it difficult to understand why there are no explicit tree classes in > the c++ standard. They generally don't have "tree" in their name ;) > tested in an afternoon, while implementing a Red Black Tree would take > considerably longer, yet the C++ standard has linked lists and not Red > Black Trees. Red-black trees are called std::map<>, std::set<> et al. in C++ since 1998. Of course std::map<> et al. doesn't *have* to be implemented as red-black, but most implementations do since the SGI STL defined std::map<> using stl_tree<>. > The library I am proposing should eventually be able to satisfy almost > anyone requiring the use of a tree. It should have many different types of > trees, Binary trees, AVL Trees, Red Black Trees, Treeps, B-Trees, > Skip-Lists, etc. It should support common methods of traversal, inorder, > preorder, postorder, and user defined traversal methods. Eventually, the > library should support an n-ary trees and their operations. Trees in the > library should also be performant, fail gracefully, be well documented, > unit and integration tested, as exception safe as possible, and, someday, Look into Boost.Intrusive. They're the most appropriate category for what you propose. Niall

1 0

Discussion Policy
by Rob Stewart 25 Apr '13

25 Apr '13

If you're relatively new to this list, you may not have taken the time to read Boost's discussion policies[1]. Even if you've been on the list for a while, reviewing the policies may be educational. Thanks for your efforts to make discussions easier and more consistent for all. ___ Rob (Sent from my portable computation engine) [1] http://www.boost.org/community/policy.html

1 0

Re: [boost] Going forward with Boost.SIMD
by Niall Douglas 25 Apr '13

25 Apr '13

> A GPU is an accelerator for large regular computations, and requiring sending > memory and receiving it back. It's also programmed with a very constrained > programming model that cannot express efficiently all kinds of operations. > > A CPU, on the other hand, is a very flexible processor and all memory is already > there. You can make it do a lot of complex computations, irregular, sparse or > iterative, can do dynamic scheduling and work stealing, and have fine-grained > control on all components and how they work together. :) You're actually wrong on that, and it's one of the first big surprises anyone who sits on ISO committees experiences: the change in scope of definitions. When you're coming at things from the level of international engineering standards, a computer's CPU is not defined as anything approximating what any of us use on a regular basis. It includes large NUMA clusters, it includes Cray supercomputers all of which don't do SIMD anything like how a PC does. It *also* includes tiny embedded 8-bit CPUs, the kind you find in watches, inlined in wiring, that sort of thing. Some of those tiny CPUs, believe it or not, do SIMD and have done SIMD for donkey's years, but it's in a very primitive way. Some of those CPUs, for example, work in SIMD 3 x 8 bit = 24-bit or even 3 x 9 bit = 27-bit not 32-bit integers, that sort of thing. Yet international engineering standards must *always* target the conservative majority, and PCs or even CPUs designed more recently than the 1990s are always in a minority in that frame of reference. Don't get me wrong: you could standardize desktop class SIMD on its own. But generally you need to hear noise complaining about the costs of lack of standardization, and I'm not aware of much regarding SIMD on CPUs (it's different on GPUs where hedge funds and oil/gas frackers regularly battle lack of interop). > However, SIMD has been here for 25 years and is still in the roadmap of future > processors. Across all this time it has mostly stayed the same. > > On the other hand GPU computing is relatively new and is evolving a lot. > It's also quite trendy and buzzword-y, and is in reality not as fast and versatile as > marketing makes it out to be. > A lot of people seem to be intent on standardizing GPU technology rather than > SIMD technology; that's quite a shame. Thing is, had Intel decided Larrabee was worth pushing to the mass market - and it was a close thing - PC based SIMD would look completely different now and we wouldn't be using SSE/NEON/AVX which is really an explicit prefetch opcode set for directly programming the ALUs and bypassing the out of order logic, not true SIMD (these are Intel's own words, not mine). As it is, convergence will simply take longer. Some of those new ARM dense cluster servers look awfully like Larrabee actually, 1000+ NUMA ARM Cortex A9's in a single rack, and their density appears to be growing exponentially for now. Given all this change going on, I'd still wait and see. Niall

4 9