I have still been keeping up my parallel programming work by a recent talk on C++0x Multithreading at BoostCon 09:
My two talks (the other one was an overview of C++0x and compiler support which can be seen here:
http://www-949.ibm.com/software/rational/cafe/blogs/cpp-standard/2009/05/26/the-view-or-trip-report-from-the-mar-2009-c-standard-meeting) seem packed with about 60 people in an auditorium for about 90 minutes. Here is a trip report from a fellow speaker Justin Gottschlich who attended my talks:
The slides and video should be online soon.
A second trip report review is by Emil Dotchevski:
Justin gave an excellent talk on a proposed Boost Transactional Memory Library which he is collaborating with the Father of TM: Maurice Herlihy.
I have been involved in Transactional Memory for a few years now and knows its hype, promise and pitfalls. Still I felt I was stirred by Justin's excellent oratory skills, pitching this technology. The idea of doing TM as a pure library is not easy, although it does get the technology into the hands of everyone as fast as possible. Language changes take time to get right. I should know and will discuss in a future post.
Please read their excellent trip reports for the details. I will turn my discussion on something else that is also interesting to me personally, but may not have much to do with Parallel programming.
BoostCon 09, as with previous BoostCon was an exciting experience. Without intentionally touting my own horn, BoostCon09 is rich with speakers of experience in the field. They choose their speaker carefully from the pantheon of C++. Last year was Bjarne Stroustrup. This year was Andrei Alexandrescu, whose topic is Iterators Must Go.
Andrei gave many reasons why iterators, once a good idea, are unsuitable as we move forward. For me, the most interesting argument is that iterators are not well suited to multithreaded programming, because many of the idea of stack pop and push can only work in single thread unless we change the interface.
BoostCon, in my opinion is rapidly becoming the leading C++ conference, in direct competition with SD West, and ACCU. All are packed with workshops, and knowledgeable speakers.
This year, there was a distinct track of parallel programming theme, which included:
- Joel Falcou: High-Level Parallel Programming EDSL - A BOOST libraries use case
- Stephan T. Lavavej: Parallel Patterns Library in Visual Studio 2010
- Justin Gottschlich, Jeremy Siek: Boost + Software Transactional Memory
- Troy Straszheim: Kamasu: Parallel computing on the GPU with boost::proto
- Michael Wong: Multithreaded C++0x: The Dawn of a New Standard
All this makes me want to suggest a special track for parallel programming for Boost in future years.
I attended some of the 0x tutorials and found that I still had things that I didn't know. This is not surprising given the depth of C++0x.
The other interesting part was the Cmake tutorial. Boost build has used bjam since the beginning. This build tool, while interesting in its own right has many peculiarities which makes its adoption not a trivial task for building Boost on IBM systems. From the stories we heard around Boostcon, the same seems to apply to other environments.
Recently, there has been a move towards using cmake as a truly better build tool. From what I can see from the workshop, they are right and I am eager to move our Boost build to a cmake system, especially if Boost is moving in that direction, to rid us of the problems that bjam has caused.
How does cmake differ form the traditional unix make?
Unlike make, it does not actually do the software build, but instead generates standard build scripts (makefiles on Unix, project file for Windows, workspaces for Eclipse/CDT), that makes it easier to adopt to various systems.
Cmake was started as part of the Insight visual ToolKit build from Kitware, and has since migrated into many products. The real explosion occurred with adoption of cmake by KDE. Since then, even more software is converting to cmake.
Cmake is so far able to build Boost, but is not able yet to run its builtin tests. This is a problem that I am sure will be rectified.
The beauty is that cmake is available already as a binary on AIX systems.
I worked with Troy Straszheim and Brad King to try getting cmake working on our Boost build. I got half way but found a problem which I hope to resolve.
We support Boost because IBM AIX and Linux xlC++ compilers have been tested with Boost with support in V8 with 1.32, then V9 with 1.34, and V10.1 with 1.34.1.
You can see our Boost test results here: