Dear members of the HiPEAC network,

I apologize for sending a long email about the compiler platform to
the global member list. This was necessary to broadcast three
important messages.

[IMPORTANT: if you are working on transactional memory:
            read point 2 and answer before Thursday.]

1. URGENT: HiPEAC compiler engineer.
------------------------------------

We are looking for a compiler engineer for the GCC
platform. The work will focus on the 4th year deliverable, which
address parallel programming support in GCC.

Important: the work can be conducted at any HiPEAC partner/member
site, for a contract of 1 year or more.

Please circulate the offer.

Note: Cupertino Miranda quit his position as HiPEAC compiler platform
engineer; he spent 10 months working on infrastructure developments
(the GCC Interactive Compilation Interface) and on supporting ongoing
research involving the toolsuite.

2. HiPEAC compiler platform cluster.
------------------------------------

The future of the GCC platform cluster was discussed at the Cambridge
meeting last month. I'll send some detailed notes to the cluster
mailing list (see point 3 below).

The main goal was to debate on the most appropriate parallel
programming model(s) we would like to support, as a community of
researchers, and beyond our short term research interests.

Two proposals where presented and debated.

- Microthreading, supported by Chris Jesshope (University of Amsterdam).
  The microthreading model is a generic set of language constructs to
  support fine-grain synchronization and communication, aiming for
  scalable and deterministic exploitation of register-level
  parallelism (decoupled ILP, DLP). During the presentation and
  discussion, its strengths were also recognized as a weakness, as the
  majority of HiPEAC researchers wish to address the concurrency
  challenges at a coarser grain. Further study of the model is
  scheduled for a future meeting, with an emphasis of programming
  language support for automatic parallelization.

- Transactional Memory (TM), supported by Intel Haifa.
  A case and implementation plan for the transactional memory model
  was presented, following email/phone exchanges between Intel Haifa
  (Avi Mendelsohn, Gad Sheaffer), Intel Santa Clara (Ali Reza
  Adl-Tabatabai), Christos Kozyrakis (Stanford University), and
  myself. The proposal builds on both Intel's and Stanford's
  developments on compiler support for TM, and more specifically on
  Christos's OpenTM paper at PACT'07. OpenTM is based on GCC and
  features well-designed interactions with the OpenMP support in GCC.

  Given the global interest of the high-performance community for TM,
  and given the strength and pragmatism of the proposed development
  plan, the meeting concluded in favor of an investment in this
  direction. We also appreciated the opportunities to factor several
  common-initerest developments through a common implementation, and
  the prospect of "deconstructing" TM as a collection of software and
  hardware features supporting other progresses in architecture and
  compilation research (including speculation, fault tolerance,
  debugging, virtualization).

  However, the limited expressiveness of TM (no expression of causal
  dependences) and its overheads are serious problems for adoption by
  a large community. In fact, it is unlikely that TM will be any
  useful for embedded systems research in the forseable future. Even
  if we decide to invest in TM support for GCC, with up to 1 man year
  in HiPEAC and more in HiPEAC-2, we will need to balance this effort
  with common-interest developments towards other programming models.

  Now, we need to come with a very quick decision.

  Several HiPEAC members work on TM (Chalmers and BSC/UPC in
  particular), and their expression of interest will be necessary to
  conclude on this matter.

  ---> If you have positive or negative opinions about HiPEAC
       supporting TM in GCC, PLEASE REACT BY THURSDAY DECEMBER 13.

  I'll send more technical information about the TM proposal to the
  cluster mailing list (see point 3 below).

Beyond these two proposals and beyond the compiler platform itself,
the participants also exxpressed an interest in supporting the
development of parallel benchmarks, to faciliate the evaluation and
comparison of programming models. This could be a global,
cross-cluster contribution of the HiPEAC network.  Feedback on this is
also welcome.