C/C++ and Fortran

 View Only

BoostCon 2010 Trip Report

By Archive User posted Thu May 13, 2010 12:34 AM

  

Originally posted by: Michael_Wong


Hi, all. I came back from BoostCon2010:
http://www.boostcon.com/program#schedule

where I delivered three talks and participated in a panel discussion on Transactional Memory, along with such luminaries as Maurice Herlihy (the father of TM), Mark Moir (Sun), and Tatiana Shpeisman, with whom I have worked with for 2 years on the Draft Specification for C++ Transactional Memory.

I gave an update of C++0x, outlining the new schedule for a Final Committee Draft that was voted in at Pittsburgh:
http://www.filetolink.com/a33a3b47

The talks on C+0x Concurrency
http://www.filetolink.com/06c4fa2d
was well attended by about 60 people and many clearly were also experts as they asked insightful questions and kept me on my toes. I was thankful that I was able to answer many of the questions.

As I was talking, I went over Clause 29 of N3092 which is our FCD.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf
Sebastien Redl and others from the audience noticed a number of editorial problems in the Atomics Operations clause, which we will submit as a National Body Comment.

Three other questions were asked at the talk for which I asked Lawrecne Crowl, and here is his answer:
1. Would it be desirableto change ATOMIC_FLAG_INIT to STD_ATOMIC_FLAG_INIT.?

It already seems pretty long and the other macros all start with ATOMIC.

2. Can the result of is_lock_free() return a different value over
time (I know they can change per iinstance)? But we though may
be i you ahve a distributed architecture, then is_lock_free()
may be different over time.

We later changed the definition to require lock_free to be consistent across objects.

The function atomic_is_lock_free (29.6) indicates whether the
object is lock-free. In any given program execution, the result
of the lock-free query shall be consistent for all pointers of
the same type.

The problem was that you need to test before you allocate.

3. Can compilers diagnose misuse of atomic types in a lock-free
contexts when a type isn't lock free for a given platform?

I think compiler can only know when it might not be lock-free,
which would probably be sufficient. All the locking operations will
likely be in a dynamic library that gets overridden to lock-free
operations on platforms that support them.

Lawrence Crowl

Wednesday brought with it a special Transactional Memory (TM) day organized by Justin Gottschlich whom I met last year, and is doing some interesting work on releasing a TM library for Boost.
http://www.filetolink.com/161ee80d
The keynote from Maurice Herlihy, gave a world-wind tour of Transactional Memory today. He highlighted the key papers of the last decade which has lead to the recent growth in TM.
http://prezi.com/3rnocqymnf84/tmtoday

He described the usual issues with synchronization overhead, privatization, lock elision, the Gartner fad cycle, while drawing a closer look the reason for some of the most vocal proponent and opponent of TM. It ended with a delivery by each of Sun, IBM and Intel on their TM offerings. I chose to spend my part talking about the different nature of the TM runtime which can be configured:
http://www.filetolink.com/0bb6fdb4

This was followed by a panel discussion where I joined with Maurice Herlihy, Mark Moir from Sun/Oracle, and Tatiana Shpeisman from Intel to describe our view of the future of TM. The panel got very lively on one topic, which was what is the one thing that TM would need in the next 2 years.

Almost everyone agree that it would have to be some kind of application conversion to TM, or using TM. It was not clear whether converting an existing application to TM would actually yield any significant benefit given that TM still has problems in several areas of common usage idiom as compared to such usage in locks. Some common cases that TM don't do well are IO, locks, dynamic libraries, or even time delays. (Imagine a time delay in an atomic transaction). These are common usage idioms inside locks today. Here is a list from Paul McKenney outlining these issues:
http://paulmck.livejournal.com/13841.html
Until TM can come up with a way to deal with these common usage idioms used today in locks, any conversion to TM will meet with the difficulties that the conversion to TxLinux met, where the they converted only some cases of locks to TM, but others had to be left as locks.

This means that TM, as some researcher suggest may be relegated to a narrowly defined domain where code does not use any such questionable operations. This is not an unappealing answer either, and it certainly simplifies the unrealistic expectation placed on TM.

As part of this TM day, we also unveiled the first public talk on the Draft Transactional Memory Specification, given by Tatiana Shpeisman of Intel.

As usual BoostCon is full of talks that opens your eyes on the possibility of C++ and Boost. Last year, I had suggested that there should be a special parallel programming day for Boost, and Justin made that a possibility. Good work Justin and thanks for inviting Maurice Herlihy, who is a fantastic guest and speaker.
As I look back, I can see the potential of Boost becoming the premier C++ Conference. It is now not just about Boost, as we are looking at all things C++, including what is coming for C++ in terms of 0x and TM. In is not hard to see a future where people will get even more from BoostCon beside Boost. I know a segment of the Boost Community is resisting that, and I don't blame them. Right now, the size as some would say is just right to have a community feel. But others would argue for expansion and growth, and the benefit that would be derived from such growth.

As usual, I always want to go to as many talks as I can because BoostCon is not just about learning, but reconnecting with people who are active in the C++ community. I saw Marshall Clow whose company was generous enough to provided some sponsorship (I heard), Nevin Lieber, Stepen Lavavej, my good friend Christophe Henry whom I hung out with afterward on a visit to a few National Park, the wonderfully funny Jeff Garland, the incredibly informative Doug Gregor, and of course the wonderful and knowledgeable Joel de Guzman, and Hartmut kaiser. New people I met including Dean Michael Berris whose blog I read from afar , and Robert Ramey because we have been working on his Serialization Library. And of course, we must not forget thanking David Abraham for being instrumental in starting such a conference as BoostCon.

I went to Eric Lieber's Proto talk and continue to marvel at the simplicity that allows C++ to be a Domain Specific Embedded language to be used by other DSELs. I thought he was a powerful speaker. He helped us with some of our Proto tests. Another good speaker is Michael Caisse who talked about Spirit, Karma, and Qi, all built upon Proto. I was intrigued by Joel Falcou's (aka Crazy Frenchmen:) Numeric Template library which uses IBM's PowerPC Hardware and others to build a Fortran-like array library using templates. This fills a niche that I find many high-performance users are looking for as they move from Fortran to C++, which is a lack of a drop-in replacement for the Fortran array syntax in C++ (Vectors still doesn't quite do it). Currently, it uses G++ on PPC (as well as a number of other hardware/compiler combination) but I would be eager to try it out with our xlC++ compiler when that library is released on Boost. They were not the only people who use IBM's PPC that I encountered and frankly the number of IBM customers I get to meet here makes this trip extremely gratifying. As usual, I can't say who they are, but you know who you are and thank-you for coming up and saying hello afterward.

Delivering three talks and being part of an Expert Panel was a bit much and made me less able to enjoy BoostCon thoroughly by attending others talks this year as I did before. However, the reaction I got was terrific and this continues to urge me to give more to the community.

9 comments
0 views

Permalink

Comments

Fri June 25, 2010 08:09 AM

Originally posted by: RobStewart


Excellent. Thanks for the update.

Fri June 25, 2010 08:06 AM

Originally posted by: RobStewart


During your Multithreaded C++0x presentation (http://www.filetolink.com/06c4fa2d), you said that std::atomic specializations for UDTs were synchronized by virtue of a single, global lock. I find nothing about that in the FCD. Is that a requirement I missed or were you referring to the current or typical implementations of which you're aware?

Wed June 23, 2010 02:32 PM

Originally posted by: Michael_Wong


Sorry for the late replies Robert. I have been traveling and is still overseas. You are right. Some of these papers are also old now and new approved copies exists. Here is the new list: Memory Model and Concurrency http://www-949.ibm.com/software/rational/cafe/community-document-picker.jspa?communityID=&subject=N2429 Concurrent Libraries http://www-949.ibm.com/software/rational/cafe/community-document-picker.jspa?communityID=&subject=N2497 Initialization listshttp://www-949.ibm.com/software/rational/cafe/community-document-picker.jspa?communityID=&subject=N2531 Rvalue references http://www-949.ibm.com/software/rational/cafe/community-document-picker.jspa?communityID=&subject=N2118 Other primary features Constant expressions, automatic types Expanded Library from most of TR1 140 features, 600 bug fixes to the standard What’s out? Concepts http://www-949.ibm.com/software/rational/cafe/community-document-picker.jspa?communityID=&subject=N2773 Garbage Collection (Replaced by smaller proposal)

The Initialization paper refers to the Intialization lists for User types. SCARY initialization was rejected, although we and others may consider it.

Mon June 21, 2010 06:17 AM

Originally posted by: RobStewart


While the current macro names may be sufficiently unique, I think not prefixing them with "STD_" sets a bad example, so I'd like to make an official comment on this. Yours is the only venue still open to me for this purpose, so please make this a Canadian National Body comment.

Sat June 19, 2010 10:22 PM

Originally posted by: Michael_Wong


Yes I somewhat agree. And I can make that a Canadian National Body comment if you wish.

Fri June 18, 2010 09:49 AM

Originally posted by: RobStewart


Could you explain the point of slides 46-48 of C++0x Update (http://www.filetolink.com/a33a3b47)? For example, slide 46 (Example 3) suggests three possible behaviors, but the comment seems to suggest that only the third is followed. Was your intent to discuss the three possibilities and then indicate that the third was chosen? The other two slides (Example 4 and Example 5) contain no useful clues to understand the point you wanted to convey.

Fri June 18, 2010 09:43 AM

Originally posted by: RobStewart


Could you explain slide 41 (New expression properties) of C++0x Update (http://www.filetolink.com/a33a3b47) for those that didn't hear you discuss it? I'm having difficulty interpreting exactly what you mean by the entries in the first column and some of the entries in the grid.

Fri June 18, 2010 08:55 AM

Originally posted by: RobStewart


In your C++0x Update presentation (http://www.filetolink.com/a33a3b47), slide 19 (What's in?), you refer to Initialization in N2116. N2116 is "Generalized Constant Expressions" which you call out in a separate bullet. I checked http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/ and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/. The only papers with "Initialization" in the title referred to SCARY (N2913 and N2980). So, to what does your Initialization bullet actually refer?

Thu June 17, 2010 10:19 AM

Originally posted by: RobStewart


The rationale to not change ATOMIC_FLAG_INIT seems weak. The other macros could likewise be prefixed with "STD_" for the same reason "STD_ATOMIC_FLAG_INIT" was suggested.