Re: [boost] The need for a 1.35.1 release
David Abrahams writes:
Hi James,
That is one of the most important reasons we decided to offer http://www.boostpro.com/products/enterprise. Maybe we can help?
Looks like there is a typo on that page... "Boostpro is a small company composed exclusively of Boost library authors. To provide you with libraries that make it easy to write write maintainable, beautiful, efficient code, the Boost internals rely on advanced C++ techniques and a strong knowledge of the ISO C++ standard document. They are written by a community of mostly-volunteer expert developers with their own distinct culture and practices." I have a bit of a beef with the efficient part at least in places -- http://webEbenezer.net/comparison.html. Preliminary results on Boost 1.35 and MSVC9 show only minor differences from the 1.34.1 and MSVC8 results. Brian Wood
On Jun 17, 2008, at 6:11 AM, brass goowy wrote:
I have a bit of a beef with the efficient part at least in places -- http://webEbenezer.net/comparison.html . Preliminary results on Boost 1.35 and MSVC9 show only minor differences from the 1.34.1 and MSVC8 results.
For 1.35 we have optimized serialization of array-like containers such as std::vector, std::valarray, C-arrays and similar, which are most important in high performance applications. There we now have performance gains of factors of 8 or more in some cases. Have you tried timing the serialization of a vector<int> ? Matthias
brass goowy wrote:
David Abrahams writes:
I have a bit of a beef with the efficient part at least in places -- http://webEbenezer.net/comparison.html. Preliminary results on Boost 1.35 and MSVC9 show only minor differences from the 1.34.1 and MSVC8
I did take a cursory look at above page which show a performance difference in two simple examples. There are a couple of problems with these small tests. The serialization library defaults for versioning and object tracking are used. Versioning provides the facitly for remaining backward compatibility with older archives. Tracking is used to permit reloading of pointers and to elmininate redudency in archives. Both of these features have a cost. Looking at the "ebenezer" code it doesn't look like these thinngs are supported. So I'm skeptical of the utility of this particula comparison. It might a little more useful to experiment with the boost serialization traits to turn off features for these types so that timings might be more comparable. But still I think, that such a limited set of tests can provide only limited insight. Never the less, I was interested in these results when you first posted them - and I continue to be. The serializaiton libray was designed to take maximal advantage of compile time code generation. The basic sequence of operations should be the same in both programs, So I would hope that there be little difference in results of tests such as yours. Any significant differences should be attributable to one or more of the following: a) Complier abstraction penalty b) test artifacts - e.g. tests running different feature sets. c) suboptimal implemenations of serialization for certain types c) bugs in the code. From time to time these have been discovered and fixed. Finally, we are slowly making progress in implementing profiling tests which we hope will isolate any performance bottlenecks. Robert Ramey
participants (3)
-
brass goowy -
Matthias Troyer -
Robert Ramey