- Boost - lists.boost.org

Vault: still needed?
by David Abrahams 23 Jan '09

23 Jan '09

Hi All, For some time now, Boostpro Computing has been hosting the Boost file valut, but now that Boost has a great Subversion host I'm beginning to wonder whether the vault is still needed. What's the case for holding onto it when people could just check their speculative work into the sandbox and subsequently merge smoothly into the Boost trunk if it is accepted? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

11 28

[1.38] Documentation - Changes in this release
by vicente.botet 23 Jan '09

23 Jan '09

Hi, I would like to start checking the documentation for the 1.38 release. I have download the one of the comressed files in http://boost.cowic.de/rc/ from the 21th January. Is this the correct address to inspect? When we can expect to see the section Change in this release completed? Thanks, Vicente

2 1

Old library version?
by Kowalke Oliver (QD IT PA SI) 23 Jan '09

23 Jan '09

Hello, I need boost 1.33.1 but it seams it is not available from the website anymore? Regards, Oliver

2 1

Re: [boost] [crypto] Ready as a debug library.
by Kasra 23 Jan '09

23 Jan '09

Hi, The boost.crypto library is on the vault at: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost_… Anyone: How could i access the boost svn?? With Best Regards Kasra

1 0

[thread] thread_specific_ptr optimizations
by Ioannis Papadopoulos 22 Jan '09

22 Jan '09

I was looking into the actual implementation of thread_specific_ptr and saw that there are actually two implementations, a generic one that uses the pthread facilities for TLS and the other one some VC-based one (I'm sorry, I'm not that proficient with MS products). I don't know if people are aware of WG21 N2659, it is the proposal for TLS (thread local storage) in C++0x http://www.open-std.org/JTC1/sc22/wg21/docs/papers/2008/n2659.htm Everyone that is using POSIX getthreadspecific and setthreadspecific (that are being currently used in thread_specific_ptr) knows that they are slower than what a compiler provides. Is there any thought of actually using any of the compiler-provided keywords to remove the need for the POSIX functions and speeding up boost::thread::get_current_thread_data()?

1 0

manipulators for filtering_stream s
by Roland Schwarz 22 Jan '09

22 Jan '09

Surprisingly I was not able to find on the net code that would give me a smart way to indent a stream. So I wrote a little filter based on the boost iostreams library. My first attempt was: boost::iostreams::filtering_ostream out; indent_filter ind(4); out.push(ind); out.push(std::cout); However trying to control it via e.g. ind.in() ind.out() turns out to be problematic interface since, 1) out.push() takes a copy of ind 2) the interface ind.in() is suboptimal. With my attached example it is possible to: #include "indent.hpp" ... boost::iostreams::filtering_ostream out; indent_filter::push(out,2); out.push(std::cout); ... And use it like so: out << "Hello Filter!\n" << indent_in << "this is\n" << "indented\n" << indent_out << "until here\n" ; Which will result in output: Hello Filter! this is indented until here The state is stored in the ios base class of the stream, by way of the pword mechanism. Consequently the filter stream even may be downcast to a basic_ostream, and the indenter will still work. E.g. with out defined as above: ... foo(out); ... void foo(std::ostream& out) { out << indent_in << "out is a downcast filter_stream\n" << indent_out << "end of indentation\n" ; } If you want to try it out, you just need to include the header indent.hpp. If someone thinks the snippet is usable either as an example for the iostreams library or the filter streams manipulator idea is worth generalizing to make it usable for other filters too, I would be glad to hear from you. -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at

5 17

[OT?] SIMD and Auto-Vectorization (was Re: How to structurate libraries ?)
by Dean Michael Berris 22 Jan '09

22 Jan '09

On Sat, Jan 17, 2009 at 5:33 PM, Joel Falcou <joel.falcou(a)u-psud.fr> wrote: > David A. Greene a écrit : >> >> Ahem: http://www.cray.com > > Two points : > 1/ Not everyone has access to a cray-like machine. Parallelization tools for > CotS machines is not to be neglected and, on this front, lots of thing need > to be done What do you mean by parallelization for CotS (Commodity off-the Shelf) machines? I personally have dealt with two types of parallelization: parallelization at a high level (dealing with High Performance Computing using something like MPI for distributed message-passing parallel computation across machines) and parallelization at a low level (talking about SSE and auto-vectorization). If you mean dealing with high level parallelism across machines, you already have Boost.MPI and I suspect you don't intend to replace that or tackle that kind of parallelism at the large scale. If you mean dealing with parallelism within a program, then you already have Boost.Thread and Boost.Asio (with the very nice io_service object to be able to use as a job-pool of sorts run on many threads). At a lower level, you then have the parallel algorithm extensions to the STL already being shipped by compiler vendors (free and commercial/prioprietary) that have parallel versions of the STL algorithms (see GNU libstdc++ that comes with GCC 4.3.x and Microsoft's PPL). > 2/ vector supercomputer != SIMD-enabled processor even if the former may > include the later. Actually, a vector supercomputer is basically a SIMD machine at a higher level -- that's if I'm understanding my related literature correctly. >> >> Auto parallelization has been around since at least the '80's in >> production machines. I'm sure it was around even earlier than that. >> > > What do you call auto-parallelization ? > > Are you telling me that, nowaday , I can take *any* source code written in C > or C++ or w/e compile it with some compiler specifying --parallel and > automagically get a parallel version of the code ? If so, you'll have to > send a memo to at least a dozen research team (including mine) all over the > world so they can stop trying working on this problem and move on something > else. Should I also assume than each time a new architecture comes out, > those compilers also know the best way to generate code for them ? I beg to > differ, but automatic parallelization is far from "done". > You might be surprised but the GNU Compiler Collection already has -ftree-vectorize compiler flag that will do analysis on the IR (Intermediate Representation) of your code and generate the appropriate SSE/SSE2/SSE3/MMX/... for your architecture. They advise adding -msse -msse2 for x86 platforms to the flags. Although I don't think you should stop with the research for better ways to do automatic vectorization, I do however think that doing so at the IR level at the compiler would be more fruitful especially when combined with something like static analysis and code transformation. You might even be surprised to know that OpenCL (the new framework for dealing with heterogeneous scalable parallelism) even allows for run-time transformation of code that's meant to work with that framework -- and Apple's soon-to-be-released new version of its operating system and compiler/SDK will be already supporting. > Then again, by just looking at the problem of writing SIMD code : explain > why we still get better performance for simple code when writing SIMD code > by hand than letting gcc auto-vectorize it ? Because GCC needs help with auto-vectorization, and that GCC is a best-effort project (much like how Boost is). If you really want to see great auto-vectorization numbers, maybe you can try looking at the Intel compilers? Although I haven't personally gotten (published and peer-reviewed) empirical studies to support my claim, just adding auto-vectorization in the compilation of the source code of the project I'm dealing with (pure C++, no hand-written SIMD stuff necessary) I already get a significant improvement in performance *and* scalability (vertically of course). I think a "better" alternative would be to help the GCC folks do a better (?) job at writing more efficient tree-vectorization implementations and transformations that produce great SIMD-aware code built into the compiler. If somehow you can help with the pattern recognition of auto-vectorizable loops/algorithms from a higher level than the IR level and do source-level transformation of C++ (which I think would be way cool BTW, much like how the Lisp compilers are able to do so) to be able to produce the right (?) IR for the compiler to better auto-vectorize, then *that* would be something else. Maybe you'd also like to look at GCC-ICI [0] to see how you can play around with extending GCC then it comes to implementing these (admittedly if I may say so) cool optimizations of the algorithms to become automatically vectorized. >> >> Perhaps your SIMD library could invent convenient ways to express those >> idioms in a machine-independent way. >> > > Well, considering the question was first about how to structure the group of > library i'm proposing, > > I apologize to not having taken the time to express all the features of > those libraries. Moreover, even with a simple example, the fact that the > library hides the differences between SSE2,SSSE3,SSE3,SSE4,Altivec,SPU-VMX > and the forecoming AVX is a feature on its own. Oh, and as specified in the > former mail, the DSL take care of optimizing fused operation so thing like > FMA are detected and replaced by the proper intrinsic when possible. Same > with reduction like min/max, operations like b*c-a or SAD on SSEx. I think I understand what you're trying to achieve by adding a layer of indirection at the library/code level -- however I personally think (and have read through numerous papers already, while doing my research about parallel computing earlier in my student days) that these optimizations/transformations are best served by the tools that create the machine code (i.e. compilers) rather then dealt with at the source code level. What I mean by this is that even though it's technically possible to implement a "parallel C++ DSEL" (which can be feasibly achieved now with Boost.Proto and taking some lessons with attribute grammars [1] and how Spirit 2(x?) with a combination of Boost.Phoenix does it) it would be reaching a bigger audience and serving a larger community if the compilers became smarter at doing the transformations themselves, rather than getting C++ developers to learn yet another library. > > Anyway, we'll be able to discuss the library in itself and its features when > a proper thread for it will start. > Maybe we can discuss it in this one? :D HTH References: [0] http://gcc-ici.sourceforge.net/ [1] http://en.wikipedia.org/wiki/Attribute_grammar -- Dean Michael C. Berris Software Engineer, Friendster, Inc.

10 29

[crypto] Ready as a debug library.
by Kasra 22 Jan '09

22 Jan '09

Hi all, The crypto library that I have been talking about is somehow ready to be seen and reviewed for suggestions and etc. So I will loads on the vault for interested parties. Kasra

3 2

[thread] proposal to manage portable and non portable thread attributes
by vicente.botet 22 Jan '09

22 Jan '09

Hello, Boost.thread has already a non portable interface to get the thread handle class thread { public: ... typedef np_native_handle_type native_handle_type; native_handle_type native_handle(); ... }; Boost.Thread do not allow to pass thread attributes on the thread constructor. I supose that this is due to portable issues. Could we identifiy which attributes are portable and which one not? The portable attributes (as stack size, ...) can be grouped on a thread_attributes class. In order to be able to pass whatever attribute to the thread constructor we can add the setting of non portable attributes to this thread_attributes class, and making the thread constructor take a thread_attributes in addition to the existing parameters. class thread { public: class thread_attributes { // portable attributes public: // set/get of attributes // .. #if defined(BOOST_THREAD_PLATFORM_WIN32) // ... window version #elif defined(BOOST_THREAD_PLATFORM_PTHREAD) private: pthread_attr_t native_attributes; public: set_np_attributes(const pthread_attr_t* h); // ... other #else #error "Boost threads unavailable on this platform" #endif }; thread(const thread_attributes*p, F f,A1 a1); ... }; The portable application needing some specific configuration can construct portable threads using the following schema thread::thread_attributes attr; // set portable attributes // ... #if defined(BOOST_THREAD_PLATFORM_WIN32) // ... window version #elif defined(BOOST_THREAD_PLATFORM_PTHREAD) // ... pthread version pthread_attr_t native_attributes; pthread_attr_init(&native_attributes); pthread_attr_setstacksize(&native_attributes, 1000000); attr.set_np_attributes(&native_attributes); #else #error "Boost threads unavailable on this platform" #endif thread th(attr, f,ctx); What do you think? Vicente

3 3

A set of individual libraries vs. One big library
by Anis Benyelloul 22 Jan '09

22 Jan '09

Hello, I was wondering if there was any interest into making the boost libraries more ``independent''? Boost contains many libraries with very different application domains. In most cases you'll want to use only one/two libraries in your project (without having to carry the whole boost code base around). But: - The files in the boost tarball are organized as if boost was a single big library: All the headers in `/boost' and all the source files together ... etc - The header file dependencies are unclear... it makes very difficult to ``extract'' just the library you need from the tarball (it is not enough to copy the directory whose name matches the library you want) It would be nice to handle this in a way similar to how ``packages'' are handled on modern Linux systems: - Each library (header+source+doc+test/..) in one directory/package (instead of having all the headers from all the libraries in the same dir, and all the tests in the same directory, all the documentation in another... etc) - A clear/automated way to handle dependencies between packages. This would help spot the ``common services'' (like boost.config) that so many libraries rely on. I think having the tarball organized in terms of individual libraries (instead of a single big one) should be the default as it make more sens from a user perspective. What do you think? Reguards, - Anis

12 24