Gr8Conf is a tricorn of a conference, it has sessions in Australia, Denmark, and USA each year. I haven't been able to get to any of the previous instances, but I did have the opportunity to get to the European part this year. I therefore submitted a proposal for a talk, about GPars, and it was accepted.
I wasn't sure on the level to pitch the presentation, for beginners, intermediates, or experts. In the end I decided to go for a "manifesto" type presentation - the long-term plan being to submit a session each year going into various different aspects of parallelism on the JVM using GPars. So somewhere between beginner and intermediate then.
The initial part of the talk was to provide an impactful and humorous argument as to why locks (semaphores, mutexes, monitors, etc., etc.) are a tool for managing time division multiplexing of multiple processes and/or threads on the processors available. It turns out that there is an interesting analogy from our front garden - if you can call such a small area a garden.
We have a number of feeding devices in our small front garden for feeding the robins, blue tits, great tits and blackbirds that live in our very urban, but right next to a cemetery, area. Cemetery, trees, squirrels. The squirrels come in and eat all the bird food they can. However, squirrels are hugely territorial and have definite "pecking order" hierarchies. The senior squirrel (in this case a female) always claims all of the bird feeding stations to the exclusion of all other squirrels. The behaviour emulates an application that demands all processor resources but only uses one at any one time. If another squirrel (process) tries to feed (use idle processors) then the senior squirrel simply chances the intruder away. One squirrel, all resources.
The point here is that any use of any explicit locking algorithm can, and does, destroy any and all parallelism. The answer is to use an architecture where the model itself manages all the processor, process, and thread resources, and, most importantly, manages the synchronization. Most application programmers no longer explicitly manage stack; most application programmers no longer explicitly manage heap; most programmers no longer explicitly manage memory; so why are programmers told how they must manage processors and threads? Wrong model, wrong abstraction.
Underlying all this is the point that processor speeds are no longer increasing, only the number of processors is increasing. Thus there is no way of increasing application performance without moving into parallel processing.
These points lead directly the re-emergence of a number of models of concurrency and parallelism that were side-lined in the rush to encompass shared-memory multi-threading as happened in the 1980s and 1990s. Actors, dataflow, Communicating Sequential Processes (CSP) and data parallelism, are now architectural and design models that application programmers need to understand and work with.
On the JVM, GPars provides a framework allowing Groovy and Java programmers a way of working with these architectural models. In this presentation I showed actors and futures using dataflow variables. I didn't get to a full dataflow version or the CSP versions due to lack of time in this 50min presentation. The application used for the code presentation was calculating "Π by Quadrature" a classic embarrassingly parallel, but small, application. Small is needed so as to exemplify the points being made rather than getting lost in large amounts of code. Anyone who has been to any of my talks in the last 5 years will know I love this problem. I also love the "Sleeping Barber" problem but we didn't get to that in this session even though I have some material on it prepared.
The "Π by Quadrature" problem allowed me to discuss using the different architectural models and to talk about using the right tool for the right problem. The right tool in this case is data parallelism and this allowed me to show a few features of GPars. It also allowed me a short rant on languages that provide one, and only one model of parallelism are not giving application programmers a suitable toolkit. Mentioning no names, and I won't, but the audience knew.
I ended the session slightly rushed so as to stay within my allotted time, with a propaganda statement that application programmers should never explicitly use any form of locking unless they absolutely have to and there is no other way. GPars has the tools to allow programmers to avoid explicit locking, to abstract away from explicitly managing processors and threads, and that therefore there was no excuse.
Audience reaction to the presentation seemed very positive, but I haven't seen the feedback. Hopefully people learned stuff as well as had a bit of entertainment.
Thanks to Søren and his team for organizing a great conference.
The slides for my presentation are here as a PDF file.
The Git repository of all the "Π by Quadrature" examples (only a few were presented) is at http://www.russel.org.uk/Git/Pi_Quadrature.git. Or if you just want to browse the code click here.
The Git repository of the "Sleeping Barber" examples (none of which were shown) is at http://www.russel.org.uk/Git/SleepingBarber.git. Or if you just want to browse the code click here.