Re: Potentially merging the transactional-memory branch into mainline.

[Torvald Riegel <triegel at redhat dot com>]

On Tue, 2011-11-01 at 10:49 +0100, Richard Guenther wrote:
> On Mon, Oct 31, 2011 at 11:33 PM, Aldy Hernandez <aldyh@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