[Haskell] ANNOUNCE: Sun Microsystems and Haskell.org joint project on OpenSPARC

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Wed Jul 23 11:52:13 EDT 2008


I am very pleased to announce a joint project between Sun Microsystems
and the Haskell.org community to exploit the high performance
capabilities of Sun's latest multi-core OpenSPARC systems via Haskell!


Sun has donated a powerful 8 core SPARC Enterprise T5120 Server to the
Haskell community, and $10,000 to fund a student, to further develop
support for high performance Haskell on the SPARC.

The aim of the project is to improve the SPARC native code generator
in GHC and to demonstrate and improve the results of parallel Haskell
benchmarks. The student will work with a mentor from Haskell.org and
an adviser from Sun's SPARC compiler team.

          ** We are now inviting applications from students **

Please forward this announcement to any and all mailing lists where you
think interested students might be lurking. Further details for
students may be found below, and on the project website.

Haskell and Multi-core Systems

The latest generation of multi-core machines pose a number of problems
for traditional languages and parallel programming techniques.
Haskell, in contrast, supports a wealth of approaches for writing
correct parallel programs: traditional explicit threads and locks
(forkIO and MVars), pure parallel evaluation strategies (par) and also
Software Transactional Memory (STM).

GHC has supported lightweight preemptable threads for a long time, and
for the last couple of years it has been able to take advantage of
machines with multiple CPUs or CPU cores. The GHC runtime has also
gained a parallel garbage collector.


We think the UltraSPARC T1/T2 architecture is a very interesting
platform for Haskell. In particular the way that each core multiplexes
many threads as a way of hiding memory latency. Memory latency is a
performance bottleneck for Haskell code because the execution model
uses a lot of memory indirections.

Essentially, when one thread blocks due to a main memory read, the
next thread is able to continue. This is in contrast to traditional
architectures where the CPU core would stall until the result of the
memory read was available. This approach can achieve high utilisation
as long as there is enough parallelism available.

The Project

GHC is increasingly relying on its native code backend for high
performance. Respectable single-threaded performance is a prerequisite
for decent parallel performance. The first stage of the project
therefore is to implement a new SPARC native code generator, taking
advantage of the recent and ongoing infrastructure improvements in the
C-- and native layers of the GHC backend. There is some existing support
for SPARC in the native code generator but it has not kept up with
changes in the GHC backend in the last few years.

Once the code generator is working we will want to get a range of
single threaded and parallel benchmarks running and look for various
opportunities for improvement. There is plenty of ongoing work on the
generic parts of the GHC backend and run-time system so the project
will focus on SPARC-specific aspects.

The UltraSPARC T1/T2 architecture supports very fast thread
synchronisation (by taking advantage of the fact that all threads
share the same L2 cache). We would like to optimise the
synchronisation primitives in the GHC libraries and run-time system to
take advantage of this. This should provide the basis for exploring
whether the lower synchronisation costs make it advantageous to use
more fine-grained parallelism.

The Server

The T5120 server has a T2 UltraSPARC processor with 8 cores running at
1.2GHz. Each core multiplexes 8 threads giving 64 hardware threads
overall. It comes equipped with 32GB of memory. It also has two 146GB
10k RPM SAS disks.


This server is a donation to the whole Haskell community. We will make
accounts available on the same basis as the existing community server as
soon as is practical. Our friends at Chalmers University of Technology
are kindly hosting the server on our behalf.

We will encourage people to use the server for building, testing and
benchmarking their Haskell software on SPARC, under both Solaris and

Student applications

This is a challenging and exciting project and will need a high
calibre student. Familiarity with Haskell is obviously important as is
some experience with code generation for RISC instruction sets.

The summer is now upon us so we do not expect students to be able to
work 3 months all in one go.

We are inviting students to suggest their own schedule when they apply.
This may involve blocks of time in the next 9 months or so. It should
add up to the equivalent of 3 months full time work.

The application process is relatively informal. Students should send
their application to:

                    opensparc at community.haskell.org

The deadline for applications in Friday 5th September 2008. If that
deadline likely to be a problem for you then do get in touch.

The application should detail skills and experience. Applications will
be reviewed by a panel including the mentor, the adviser from Sun and a
number of other Haskell.org community members who have helped with
reviewing student projects in the past. The review will be partly
interactive; students can expect to get questions and feedback from the

Students are welcome to contact myself or anyone else to help improve
the quality of their application or if they have any questions.

The $10k student funding will be paid in three phases, at the
beginning ($3k), an intermediate point ($3k) and at the end ($4k). The
exact timing will depend on the agreed schedule. The intermediate and
final payments will be subject to positive reviews from the mentor.

(project coordinator)

More information about the Haskell mailing list