On Mon, Oct 22, 2007 at 08:26:58AM +0200, Lars Gullik Bjønnes wrote: > Andre Poenitz <[EMAIL PROTECTED]> writes: > > | > Just let me add something... gcc 4.3's stdlibc++ will have support for > | > a paralell mode, where some of the standard algorithms (and some other > | > stuff) will automatically be able to take advantage of multi-core and > | > smp. > | > | Using OpenMP? > > The mechanics of it, yes. > > | > This also sees to be the trend for this kindo of paralallization: do > | > it in the compiler and/or the support libraries instead of forcing > | > applications to handle all threading themselves. > | > > | > So, for us to take advantage of some multi-processing almost for free, > | > it is important to use std::algorithms when possible. > | > | Well, to be honest, I doubt that this will buy us much. Using cutting > | edge boost lately caused quite some problems and I have no reason to > | believe that a new gcc will magically solve all problems. Also lately, > | precompiled headers looked more linke a hindrance then a benefit, so > | I'd be more that happy if gcc would perform like, say, icc. > > Precompiled headers does not change code... just a trick to (try to) > compile faster)
I know. How ever last time I did timings for LyX with and without precompiled headers using them was slower. > auto-vectorization and auto-paralellization is imho becoming more and > more imporatant. (and this is what the next version of icc supports > really well, and gcc 4.3 will also make some rather big strides here) Depends on the use case. OpenMP works fairly well for "hardcore numerics". The benefits for general purpose applications I've seen so far are rather slim. And yes, I used it for a while... > But sure, getting threading into the C++ language proper will give us > a lot more. esp. the simple use of futures. I am already faily happy using QtConcurrent (http://labs.trolltech.com/page/Projects/Threads/QtConcurrent)... > | Of course, in code like > | > | #if 0 > | int lf = 0; > | docstring::const_iterator dit = s.begin(); > | docstring::const_iterator end = s.end(); > | for (; dit != end; ++dit) > | if ((*dit) == '\n') > | ++lf; > | #else > | int lf = std::count(s.begin(), s.end(), char_type('\n')); > | #endif > | > | I certainly prefer the second version as it is shorter to read. But > | replacing a three-line-for-loop by some construct using helper classes, > | bind etc I do not consider a win. > > It all depends. Being able to give those three lines a name is imho > almost always a win. if that is gotten through using std::algorithms > or refactoring the three lines into its own function is not > important, but clear self-documenting code is better than comments. > (and naming is really important to accomplish that) Too small units make code hard to understand, too, as even though the units themnselves are understandable, the bigger picture of how things works together is missing... Andre'
