On Tue, 2011-11-01 at 10:49 +0100, Richard Guenther wrote: > On Mon, Oct 31, 2011 at 11:33 PM, Aldy Hernandez <al...@redhat.com> wrote: > > This is somewhat of a me-too message for the transactional-memory work. We > > would also like it to be considered for merging with mainline before the end > > of stage1.
[snip] > > The final word > > ============== > > Seeing that a global maintainer has been lead on this for a while, I suspect > > there isn't much to review formally. I believe the only bits that Richard > > isn't directly responsible for are the C++ front-end changes. > > > > So what is the opinion/consensus on merging the branch? It would be nice to > > get this infrastructure in place as well so we can get people to start using > > it, and then we can work out any issues that arise. > > > > I have no idea how this happened, but apparently I'm on the hook for merging > > both the cxx-mem-model and this branch (if/when one/both get approved). If > > this gets approved, I'd prefer to get the cxx-mem-model branch merged first, > > and the transactional-memory branch later during the week. I will be > > partially available during the weekend, and definitely during next week. > > Given that you only recently merged with trunk again are you really > sure this is a great > idea at this point in time? Yes, for the reasons outlined below. > Does the GCC 4.7 user community benefit from this > in any way (or rather how much percentage of it)? Yes, we think so. Transactional Memory (TM) is a very easy-to-use synchronization mechanism, which does not burden the programmer with having to consider issues such as deadlocks or having to rely on conventions regarding which locks cover which data. This complements the recent efforts for low-level synchronization in GCC (ie, C++11 atomics) and other threading-related features in C++11. It is a new feature that isn't yet available in other mainstream compiler products, but there is wide industry interest in TM. The TM language specification for C++ that we have implemented in the branch is the output of a cross-industry working group consisting of people from HP, IBM, Intel, Oracle, and Red Hat. This group, including C++11 and synchronization experts such as Hans Boehm, has been working since at least 2009 on this specification, and we are pretty confident that we have a good understanding of the matter, and which programming abstractions we can and should offer. We have presented it to and discussed it with several other affected parties (e.g., Boost folks, academia, ...), and we hope to present it to the C++ standard community in February. On the hardware side, there clearly is interest too. For example, IBM BlueGene/Q chips have hardware support for TM, and AMD released a proposal for such support for x86 (AMD's Advanced Synchronization Facility). Thus, we are not investing in some wild and crazy idea here. In contrast, because other mainstream compilers do not have this feature yet (but do have in preview versions, e.g., in an ICC what-if prototype), it is actually an opportunity for GCC to offer improvements for its users first before other compilers do. Parallelization and synchronization are of interest to many GCC users I would argue, so giving them another reason to use GCC is definitely good. Also, this is an area that will become even more important in the future. > Thus, please consider merging early during GCC 4.8 stage1 instead. I do think that merging now is definitely better than waiting another cycle: - It does improve GCC for programmers that have to build concurrent code. We know that the percentage of these programmers will increase. - TM does not negatively affect any other features of GCC from the perspective of users, because TM as we have implemented it smoothly embeds into the C++11 memory model (but without actually being dependent on its implementation or presence) and does not create other dependencies. Do you see any examples for negative effects on other features? - The TM code in GCC is also pretty isolated from anything else; while there is front-end support, most of the implementation and logic is in an isolated runtime library (libitm). - We (here meaning my colleagues and myself) definitely have the expertise to maintain this, and we are willing to invest time in this in the future. Overall, this looks like much benefit, very little costs to me. The sooner we make this available in mainline, the earlier users can benefit from it. Torvald