January 2009 - Boost - lists.preview.boost.org

[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

Compilation errors upgrading boost from 1.34 to 1.37 (Windows)
by mborghi2 22 Jan '09

22 Jan '09

Dear all, I've just upgraded the boost library from 1.34 to 1.37 on Windows. When I try to compile our software with the new library version (both with VS 7.0 and with VS 9.0) I meet 2 different kind of problems. In our software we instantiate the class boost::recursive_mutex::scoped_lock (instance of the template unique_lock), and one problem seems that the class boost::recursive_mutex doesn't implement the function unlock_upgrade_and_lock. I'm compiling the code settings the define BOOST_THREAD_WIN32, I don't know if there are others defines to be specified. Follow the VS 9.0 output (with the compilation errors): ... 1>d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(406) : warning C4661: 'boost::unique_lock<Mutex> &boost::unique_lock<Mutex>::operator =(boost::upgrade_lock<Mutex> &)' : no suitable definition provided for explicit template instantiation request 1> with 1> [ 1> Mutex=boost::recursive_mutex 1> ] 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(215) : see declaration of 'boost::unique_lock<Mutex>::operator =' 1> with 1> [ 1> Mutex=boost::recursive_mutex 1> ] 1>d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(406) : warning C4661: 'boost::unique_lock<Mutex> &boost::unique_lock<Mutex>::operator =(boost::upgrade_lock<Mutex> &)' : no suitable definition provided for explicit template instantiation request 1> with 1> [ 1> Mutex=boost::mutex 1> ] 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(215) : see declaration of 'boost::unique_lock<Mutex>::operator =' 1> with 1> [ 1> Mutex=boost::mutex 1> ] 1>d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(406) : warning C4661: 'boost::unique_lock<Mutex> &boost::unique_lock<Mutex>::operator =(boost::upgrade_lock<Mutex> &)' : no suitable definition provided for explicit template instantiation request 1> with 1> [ 1> Mutex=boost::recursive_timed_mutex 1> ] 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(215) : see declaration of 'boost::unique_lock<Mutex>::operator =' 1> with 1> [ 1> Mutex=boost::recursive_timed_mutex 1> ] 1>d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(786) : error C2039: 'unlock_upgrade_and_lock' : is not a member of 'boost::recursive_mutex' 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\win32\recursive_mutex.hpp(22) : see declaration of 'boost::recursive_mutex' 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(780) : while compiling class template member function 'boost::unique_lock<Mutex>::unique_lock(boost::detail::thread_move_t<T>)' 1> with 1> [ 1> Mutex=boost::recursive_mutex, 1> T=boost::upgrade_lock<boost::recursive_mutex> 1> ] 1> d:\masterfinancedevl\admindevl\devl\src\include\mfcoreutility\mutexwrapper.h(114) : see reference to class template instantiation 'boost::unique_lock<Mutex>' being compiled 1> with 1> [ 1> Mutex=boost::recursive_mutex 1> ] 1>d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(786) : error C2039: 'unlock_upgrade_and_lock' : is not a member of 'boost::mutex' 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\win32\mutex.hpp(22) : see declaration of 'boost::mutex' 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(780) : while compiling class template member function 'boost::unique_lock<Mutex>::unique_lock(boost::detail::thread_move_t<T>)' 1> with 1> [ 1> Mutex=boost::mutex, 1> T=boost::upgrade_lock<boost::mutex> 1> ] 1> d:\masterfinancedevl\admindevl\devl\src\include\mfcoreutility\mutexwrapper.h(129) : see reference to class template instantiation 'boost::unique_lock<Mutex>' being compiled 1> with 1> [ 1> Mutex=boost::mutex 1> ] 1>d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(786) : error C2039: 'unlock_upgrade_and_lock' : is not a member of 'boost::recursive_timed_mutex' 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\win32\recursive_mutex.hpp(42) : see declaration of 'boost::recursive_timed_mutex' 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(780) : while compiling class template member function 'boost::unique_lock<Mutex>::unique_lock(boost::detail::thread_move_t<T>)' 1> with 1> [ 1> Mutex=boost::recursive_timed_mutex, 1> T=boost::upgrade_lock<boost::recursive_timed_mutex> 1> ] 1> d:\masterfinancedevl\admindevl\devl\src\include\mfcoreutility\mutexwrapper.h(144) : see reference to class template instantiation 'boost::unique_lock<Mutex>' being compiled 1> with 1> [ 1> Mutex=boost::recursive_timed_mutex 1> ] 1>d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\win32\basic_recursive_mutex.hpp(64) : error C2679: binary '+' : no operator found which takes a right-hand operand of type 'const boost::xtime' (or there is no acceptable conversion) 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\date_time\posix_time\date_duration_operators.hpp(31): could be 'boost::posix_time::ptime boost::posix_time::operator +(const boost::posix_time::ptime &,const boost::gregorian::months &)' [found using argument-dependent lookup] 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\date_time\date_duration_types.hpp(132): or 'boost::gregorian::date boost::date_time::months_duration<base_config>::operator +(const boost::gregorian::date &,const boost::date_time::months_duration<base_config> &)' [found using argument-dependent lookup] 1> with 1> [ 1> base_config=boost::gregorian::greg_durations_config 1> ] 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\date_time\posix_time\date_duration_operators.hpp(75): or 'boost::posix_time::ptime boost::posix_time::operator +(const boost::posix_time::ptime &,const boost::gregorian::years &)' [found using argument-dependent lookup] 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\date_time\date_duration_types.hpp(244): or 'boost::gregorian::date boost::date_time::years_duration<base_config>::operator +(const boost::gregorian::date &,const boost::date_time::years_duration<base_config> &)' [found using argument-dependent lookup] 1> with 1> [ 1> base_config=boost::gregorian::greg_durations_config 1> ] 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\date_time\time.hpp(138): or 'boost::posix_time::ptime boost::date_time::base_time<T,time_system>::operator +(const boost::date_time::date_duration<duration_rep_traits> &) const' 1> with 1> [ 1> T=boost::posix_time::ptime, 1> time_system=boost::posix_time::posix_time_system, 1> duration_rep_traits=boost::gregorian::date_duration_rep 1> ] 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\date_time\time.hpp(158): or 'boost::posix_time::ptime boost::date_time::base_time<T,time_system>::operator +(const boost::posix_time::time_duration &) const' 1> with 1> [ 1> T=boost::posix_time::ptime, 1> time_system=boost::posix_time::posix_time_system 1> ] 1> while trying to match the argument list '(boost::system_time, const boost::xtime)' 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(364) : see reference to function template instantiation 'bool boost::detail::basic_recursive_mutex_impl<underlying_mutex_type>::timed_lock<boost::xtime>(const Duration &)' being compiled 1> with 1> [ 1> underlying_mutex_type=boost::detail::basic_timed_mutex, 1> Duration=boost::xtime 1> ] 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(363) : while compiling class template member function 'bool boost::unique_lock<Mutex>::timed_lock(const boost::xtime &)' 1> with 1> [ 1> Mutex=boost::recursive_mutex 1> ] ... Have you any suggestion on how to solve our compilation problem? thanks in advance best regards Matteo -- View this message in context: http://www.nabble.com/Compilation-errors-upgrading-boost-from-1.34-to-1.37-… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Re: [boost] Should we PING the ML when there is no answer at all to a post?
by JOAQUIN M. LOPEZ MUÑOZ 21 Jan '09

21 Jan '09

_______________________________________ De: boost-bounces(a)lists.boost.org [boost-bounces(a)lists.boost.org] En nombre de vicente.botet [vicente.botet(a)wanadoo.fr] Enviado el: miércoles, 21 de enero de 2009 19:55 Para: boost(a)lists.boost.org Asunto: [boost] Should we PING the ML when there is no answer at all to a post? > > Hi, > > sometimes the posts are not answered at all, either because there is no interest, > or because the post is lost between the others. > > I would like to know if it is a good idea to PING the ML when there is no answer at > all to a post. I've done it several times in the past and got no reprimand from the moderators, so I guess it's OK to do it with some restraint. > If yes, how and when this PING must be done? Repost the entire mail and add a [repost] prefix to the subject line. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Should we PING the ML when there is no answer at all to a post?
by vicente.botet 21 Jan '09

21 Jan '09

Hi, sometimes the posts are not answered at all, either because there is no interest, or because the post is lost between the others. I would like to know if it is a good idea to PING the ML when there is no answer at all to a post. If yes, how and when this PING must be done? Thanks, Vicente

1 0

[thread] locks.hpp double declaration of unique_lock(unique_lock&& other)
by vicente.botet 21 Jan '09

21 Jan '09

Hi in lines 248-255 of the file boost/thread/locks.hpp we found the unique_lock(unique_lock&& other) declaration twice one withoth explicit and defined and the other with explicit an undefined. #ifdef BOOST_HAS_RVALUE_REFS unique_lock(unique_lock&& other): m(other.m),is_locked(other.is_locked) { other.is_locked=false; other.m=0; } explicit unique_lock(upgrade_lock<Mutex>&& other); Could you say me why this is nesded? _____________________ Vicente Juan Botet Escribá

3 3

[iostreams] Error reporting for buffered streams
by Eric MALENFANT 21 Jan '09

21 Jan '09

By default, filtering_streams do buffering. This means that what is written to them does not necessarily reach the underliyng Filters and Device immediately. It is thus my understanding that, in order to be sure that all data was written, one should somehow flush the buffered data, and then check the stream state before closing it. As a first attempt, I tried flush(), but it does not seem to do what I expected. Looking at the docs, I then found what seemed to be what I was looking for: strict_sync(), whose documentation states that "A return value of true guarantees that all buffered data has been successfully forwarded.". Moreover, the FAQ entry "Can I swap Filters or Devices in the middle of a sequence of i/o operations?" seems to confirm this, as it says: "First call strict_sync. If it returns true, you can safely call set_auto_close(false) and pop one or more components without closing the stream. This applies to instances of filtering_stream, filtering_streambuf and chain." But again, this did not work: strict_sync() returns true although buffered data remains. Consider this contrived example: // A codecvt facet that always fails class always_fail_cvt : public std::codecvt<wchar_t,char,mbstate_t> { protected: virtual result do_out( state_type&, const intern_type*, const intern_type*, const intern_type*&, char* to, char*, char*&) const { return std::codecvt_base::error; } //... }; int main(int argc, char* argv[]) { std::wofstream fs("whatever"); fs.imbue(std::locale(fs.getloc(), new always_fail_cvt)); boost::iostreams::filtering_wostream s(fs); s << L"Hello"; std::cout << std::boolalpha << s.good() << ', '; s.flush(); std::cout << s.good(); return 0; } Running this (on Windows with MSVC 7.1) produces "true, true" The first "true", is not surprising, as the characters are buffered and code conversion has not taken place yet, but the second is. (to me at least). Considering the presence of strict_sync(), I assumed that the "forgiveness" of flush() is intentional, to allow stateful filters to retain buffered data, maybe. However, replacing the "s.flush();" line in the above program with "std::cout << s.strict_sync() << ", ";" does not seem to change things much. Even though a conversion failure occured and data remains buffered, strict_sync() returns true, and the stream's state is still good(). So, to sum up: 1) If my understanding of the semantics of strict_sync() is correct, it seems that indirect_streambuf::strict_sync() should verify that the buffer is empty after the call to sync_impl(), and fail if it is not the case. Something like this maybe: template<typename T, typename Tr, typename Alloc, typename Mode> bool indirect_streambuf<T, Tr, Alloc, Mode>::strict_sync() { try { // sync() is no-throw. sync_impl(); return obj().flush(next_) && ((pptr() - pbase()) == 0); // Added this --^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ } catch (...) { return false; } } 2) Is it "correct" that filtering_stream::flush() does not completely flush without reporting an error? 3) Does this come from an incompatibility between Boost.IOStreams idea of error-reporting (throwing exceptions) and that of the std streambufs (returning EOF, mainly)? In particular, Boost.IOStreams writes in a wrapped std::streambuf by using sputn(), which, AFAI(don't)U, does not have a clear error reporting strategy. IOWs, should write_device_impl<streambuf_tag>::write() be modified so that it reports errors by an exception. Something like this maybe: template<typename T> static std::streamsize write (T& t, const typename char_type_of<T>::type* s, std::streamsize n) // { return t.sputn(s, n); } { std::streamsize count = t.sputn(s, n); if (count == n){ return count; } // If all characters could not be written, check if it is because of an error or only because of blocking if (T::traits_type::eq_int_type(t.sputc(s[count]), T::traits_type::eof())){ throw std::ios_base::failure("write error"); } else{ return count + 1; } } Sorry for the longish post, and thanks for reading up to here, Éric Malenfant

1 0

[random] A much faster Poisson variate generation
by Ross Levine 21 Jan '09

21 Jan '09

Hello, I have modified the poisson_distribution class to use an updated version of Ahrens and Dieter's PD algorithm for generating Poisson variates, as described in "Computer Generation of Poisson Deviates from Modified Normal Distributions." Is this allowed in Boost, and is there interest? The current algorithm is O(mean), while PD is bounded time. In addition, the current implementation fails for mean >> 750. PD does, however, use a lookup table and thus has a non-trivial constructor and needs 36 * sizeof(RealType) + 1 * sizeof(IntType) bytes per poisson_distribution object. Please let me know if this is desired. Ross

2 7