Parallelism can be Groovy

I will be doing a session 2011-01-13T18:00+00:00 for the BCS Advanced Programming Specialist Group entitled "Parallelism can be Groovy". It is not a coincidence that the title is exactly the same as the one for a "webinar" that the BCS Distributed and Scalable Computing Speciailist Group tried to put on with me as presenter 2010-03-17T17:30+00:00, but which didn't actually work (for various reasons). This new session isn't of the exactly the same material - the world has moved on so much in the last nine months! - but it is about the same ideas.


Traditionally parallel programming has been seen as the preserve of C, C++ and Fortran. Tools such as MPI and OpenMP have become the de facto standard tools. This mindset has come out of the HPC milieu and the HPC community seem not to be looking for any other options.

As the Multicore Revolution has meant that every computer is now a parallel processing computer, all programming is becoming parallel programming. In the worlds of desktops and web services the main programming languages are Java and Python. These languages have incorporated a threads model since their inception. So successful has these been till now, even C++ is getting a standard threads model. MPI and OpenMP have been tried in the Java, Python and C# community, but have basically failed to work. They are tools likely only ever to be used in HPC with C, C++ and Fortran.

The problem of threads use is that it introduces the age old problems of locking and synchronization. Issues that the average programmer finds hard, very hard. Often impossibly hard. What is the root of the problem? Shared memory multi-threading. What is the answer? Don't use shared memory multi- threading! Obvious really.

So what are the alternatives? Actually they have been known for a long while: the Actor Model, dataflow, and communicating sequential processes (CSP). There is also the more recent, but still well known, idea of software transactional memory.

In the Java milieu, Scala has opted to highlight the Actor Model as the principle tool of concurrency and parallelism. In the Python milieu there is a move to providing support for lightweight processes via the multiprocessing package.

There are layers of language here:

  1. Native, statically typed: C, C++, Fortran
  2. Virtual machine, statically typed: Java, Scala
  3. Virtual machine, dynamically typed: Python, Groovy, Clojure

What is becoming clear, is that the dynamically typed languages have an increasingly strong role to play as "coordination languages". These languages have meta-object protocols which means that creating domain specific languages is very straightforward.

Taking Groovy as an example, the GPars project is creating a language for describing the structure and management of parallel computations on the JVM, both locally (utilizing the multi-threaded nature of the JVM), and also cluster-like (utilizing the latest NIO-based distributed systems infrastructure). Initially focused on providing Actor Model infrastructure for Java/Groovy systems, attention is now turning to dataflow and especially to CSP.

The presentation will focus on demonstrating the role that dynamically typed language have in the future of parallel computation.


Copyright © 2005–2020 Russel Winder - Creative Commons License BY-NC-ND 4.0