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

Performance of boost::mutex and boost::mutex::scoped_lock
by Zachary Turner 13 Jun '09

13 Jun '09

I have been doing some profiling using VTune recently to investigate the cause of some underperforming multi-threaded code, and it's possible that I'm not interpreting these results correctly, but if I am it's a little surprising. This isn't the best multi-threaded design in the world, but it's basically a naive implementation of a producer consumer that uses a deque as the production queue, a boost::mutex as the lock, and a boost::condition as a signal to wake up when there's stuff in the queue (queue comment about boost::circular_buffer, which this code really should be using instead). There is LOTS of context switching going on, basically I read a 4KB chunk of data from the filesystem, put it in the queue, the other threads takes the 4KB of data, does something with it, and this repeats for a really long time. Since it doesn't take a whole lot of time to read 4KB of data from the disk, you can tell that there are going to be zillions of context switches and contention going on. So on to the point. Obviously most of the time is spent in boost::detail::basic_timed_mutex::lock, but what's surprising is the breakdown of time inside the lock function: (Keep in mind this is not timed over a terribly long sample, hence the small numbers, but it is over thousands of actual locks, and ultimately this locking alone makes up a noticeable portion of the sample duration) boost::detail::basic_timed_mutex.lock Total Time: 1,032,486 microseconds (1.032 seconds) Total Wait Time: 505,884 microseconds (.505 seconds) It appears that only half the time is actually spent inside the lock, which is pretty crazy. The rest is spent doing computations, which doesn't seem right for a lock. I drilled down further and came up with this: boost::detail.get_system_time_sentinel Total Time: 266,657 microseconds Total Wait Time: 264 microseconds So that accounts for about half of the computational time. The rest is in a Windows system call somewhere that I was not able to drill into. I don't know about the details of date_time library, or much about the details of thread library either for that matter, but why is a time necessary here at all? This is eventually resolving down to a boost::detail::basic_timed_mutex, but there's nothing timed about the operations I've done. I simply did the following: boost::mutex m; boost::mutex::scoped_lock lock(m); //... This should ultimately result in an infinite timeout being specified to the system call, so all of this computation seems completely unnecessary. It seems like a scoped_lock should completely bypass anything having to do with date_time, and perhaps even normal timed locks should come up with a more efficient strategy. Thoughts?

4 4

[mpl] mpl::string, ok to merge to release?
by Eric Niebler 13 Jun '09

13 Jun '09

The mpl::string tests look OK to me on trunk, so I was planning on merging this to release for 1.40. Objections? Aleksey, I've had some problems generating the refmanual html from the rst source. It seems to go OK, but then some of the internal links are broken, and I can't figure what I'm doing wrong. Could you generate new html from the rst on trunk and commit it back to trunk? Please let me know the revision number after you do, and I'll merge it all to release in one go. Thanks. -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 3

Re: [boost] boost::directx?
by Kasra 13 Jun '09

13 Jun '09

Hi guys, I have been following this thread but haven't really found the significance of boost::directx! If the purpose of the library is to create a comprehensive graphics library, choosing directx or infact any other API seems absurd. For example, ORGE is a graphics library that doesn't choose OpenGL over DirecX but provides a wrapping interface for a graphics library where this library's internal is OpenGL and DirectX depending on the platform. I just think if this library is going to established within boost, it requires a portable interface irrespective of the internals. With Best Regards --- Kasra Nassiri

16 41

Why the integration branchmust remain clean, etc.
by David Abrahams 12 Jun '09

12 Jun '09

I just realized I can articulate what's not working for me about the current trunk/release branch arrangement. * IIUC, there are always lots of failures on the trunk because there's no pressure to keep it clean. * Before I check in a change in one of my libraries, I want to make sure I haven't broken anything else in boost. So naturally, I run the whole regression suite (there oughta be a better way!) * But since the trunk is not clean, I spend a lot of time analyzing problems that have nothing to do with my library. That's a real disincentive to making changes in Boost. In fact, I am confident my low activity in the repo over the last year or so is primarily caused by the amount of labor associated with testing my changes. Now, maybe you'll suggest that I test my own library, then damn the torpedoes and check in the changes, and let other people complain to me when their libraries break. That would work... except that many people aren't paying attention to the health of their libraries on the trunk. I suppose another approach might be to test against the release branch, then svn switch to the trunk and check in my changes there. But that is still laborious. I'm not sure what to do about this, but it's really killin' me. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

5 10

Some good news for boost
by David Abrahams 12 Jun '09

12 Jun '09

Apparently we've been selected as an "alternate finalist" in the SourceForge Community Choice awards! They want us to answer some questions and provide some supporting material. If anyone else in the community would like to contribute to answering questions 1 and 2 below, that would be awesome. Marshall, you're the only person I know of that has any Boost-related video. What do you think about #4? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

5 5

Documentation Edits
by Zachary Turner 12 Jun '09

12 Jun '09

What is the standard protocol for editing documentation? It doesn't appear to be a wiki, unless you have to explicitly request write access in which I wasn't aware of that. The reason I ask is that there are many times where I've spent forever toiling over the documentation of some new library that I wasn't familiar with, because the documentation either provided no / insufficient samples, functions with very general names and one-liner documentation that says (for example) "runs the service". Which is pretty obvious when the function is called run, but no mention of the implications or what "running" even means. Other examples include lack of discussion over memory ownership (I spent 6 hours yesterday trying to trace down a memory corruption only to later find that in one of the many example programs for the library a single line comment that said "this causes X to take ownership of Y". If that had been in the documentation I would have spent 5 minutes tracing down the bug. So my point in all this is can the documentation be in wiki format, and as a fallback is there a way that someone other than a library owner/maintainer can edit it?

2 1

Re: [boost] Possible problem: Christian Schladetsch
by John Maddock 12 Jun '09

12 Jun '09

> Let's not turn an accidental mailing into a tar and feather. All things > said and done, he is at least attempting to contribute something to the > community. Indeed, can we please consider this thread closed now, Thanks, John Maddock. Boost Moderator.

1 0

1.40.0 showstoppers
by Vladimir Prus 12 Jun '09

12 Jun '09

During last release cycle, we talked that there should be a way to flag some issues as showstoppers for next release, so that next release is either delayed until the issue is fixed, or the issue is explicitly downgraded by the release team after consideration. However, I am not sure we've reached definitive agreement on how such issues should be marked. One proposal is to use the 'showstopper' status. Does that sound OK to our release managers? If so, shall this convention be documented somewhere, and should release procedures be adjusted to including checking this list prior to rolling betas and final release? I can do the necessary edits if everybod agrees, and tell me what to edit. Thanks, Volodya

1 0

Re: [boost] "boost cold shoulder" (was proposal for #pragmaonce support)
by Brian Wood 11 Jun '09

11 Jun '09

Sid Sacek writes: > I believe I belong to a third category that you didn't mention below: > 3. The middle-aged mellowed-out "try to always do the right thing", > "using namespace boost", crowd. I don't think doing the right thing implies automatically using a Boost library, but rather considering the options. I encourage people to "chew the meat and spit the bones" when it comes to Boost. Some of the libs are very helpful and are implemented well. Other libs have some problems -- http://webEbenezer.net/comparison.html<http://webebenezer.net/comparison.html> . I will say though that doing the right thing in my book usally means using Boost Intrusive and that Ebenezer Enterprises offers exclusive marshalling/serialization support for two Boost Intrusive containers. If there's interest in having marshalling support for other Intrusive containers, we are willing to consider adding more support in that area. Brian Wood Ebenezer Enterprises www.webEbenezer.net <http://www.webebenezer.net/> "Then Samuel took a rock and set it up between Mizpah and Shen. He named it Ebenezer [Rock of Help] and said, 'Until now the L-RD has helped us.'"

1 0

[multi_array] Negative strides
by John Reid 11 Jun '09

11 Jun '09

I could not find any support in boost::multi_array for negative strides. Does anyone know what the rationale was for not implementing them? John.

3 6