Russel Winder's Website

On CPython, PyPy and Jython

At the session "Python is a High Performance Language" last evening, I showed some Python code executed using CPython and PyPy. John Hoyland asked what the performance was with Jython or IronPython. An excellent question about which I had no data. I will not be able to check with IronPython on CLR, but I can certainly check Jython. Using the sequential version of my "π by quadrature" using a for loop with xrange and multiplication, the code for which can be found here, I get the following results:

  • CPython:

==== Python Sequential For/Xrange Multiply pi = 3.14159265359 ==== Python Sequential For/Xrange Multiply iteration count = 10000000 ==== Python Sequential For/Xrange Multiply elapse = 5.83972406387

  • PyPy:

==== Python Sequential For/Xrange Multiply pi = 3.14159265359 ==== Python Sequential For/Xrange Multiply iteration count = 10000000 ==== Python Sequential For/Xrange Multiply elapse = 0.224266052246

  • Jython:

==== Python Sequential For/Xrange Multiply pi = 3.14159265359 ==== Python Sequential For/Xrange Multiply iteration count = 10000000 ==== Python Sequential For/Xrange Multiply elapse = 6.33100008965

So I think it fair to say, without fear of contradiction, that PyPy Rocks.

The PyPy Project needs your help. The project relies on voluteer labour and donations. Currently it is trying to ensure PyPy can work with NumPy and that PyPy conforms to the Python 3 specification. Donate individually on the PyPy home page, get your company to donate. PyPy needs your help.

Python is a High Performance Programming Language

Yesterday evening (starting 2012-01-31T18:34) I presented a session with the above title at Skills Matter. It was scheduled in their "In the Brain" series, so I assumed licence to be very personal and idiosyncratic. The overall aim of the session was to convince people that although Fortran and C++ are seen as the standard languages of high performance computing (HPC), Python has a place. I opened with promise of a pair of arguments that then came together as a form of "proof of case".

The first argument was to address "high performance" as a term implying the ability to create correct (and fully tested) solutions to problems quickly and with small amounts of code. The implication being that high performance is about the ability of programmers to use the tools to great effect. I emphasized "ceremony", in particular "low ceremony" and "high ceremony" as a major factor: "ceremony" here being code that has to be written to satisfy the compiler that contributes nothing to the code that actually executes. Python is very definitely a "low ceremony" language associated with the fact that it is a dynamic language. Traditionally statically typed languages have been "high ceremony" and dynamically typed languages have been "low ceremony". The question is whether the drive to type inference in all the major statically typed languages (D, C++, Java, Scala, Haskell) reduces the level of ceremony to be equal to that of the dynamically typed languages.

This led to the issue of meta-object protocols (MOPs). All the major dynamically typed languages (Python, Ruby, Groovy, Lisp, Clojure) have run time MOPs in one guise or another, and this gives them great capabilities in creating domain specific languages (DSLs) as internal languages. C++ and D even though they are statically typed languages have MOPs; it is just they are compile time MOPs rather than run time ones. So there can be no dynamism to the DSL, but they are still very capable of creating DSLs - just static ones. Although not stated explicitly the issue of internal DSLs leads directly to the idea of coordination languages, and in the context of HPC to parallelism coordination languages.

I then switched tack to address computational performance as the focus of "high performance" ; arguably the more traditional interpretation of the term. Python performs badly compared to C++ and Fortran, generally about 50 to 200 time slower, at least using the CPython interpreter. PyPy performs somewhat better being 10 to 20 times faster on the small microbenchmarks I showed that CPython. As ever for me this was calculating a quadrature approximation to the value of π. The problem is small, embarrassingly parallel and never ceases to be able to be used for showing issues associated with parallelism in any number of languages. (All the code for this problem is available in a Bazaar branch here: feel free to browse or branch, if you branch please let mw know of any amendments or additions.) Both CPython and PyPy have a global interpreter lock (GIL) which means no parallel execution of threads at all. This can be got round in three fundamental ways:

  1. Remove the GIL. This is unlikely to happen in CPython, but the PyPy folk are experimenting with software transactional memory (STM) as a way of being able to remove the GIL.
  2. Use the multiprocessing package (or Parallel Python) to make use of multiple Python virtual machines (PVMs) each of which runs a single threaded process.
  3. Use native code PVM extensions for the parallel computations.

Using Python for the bulk of the code, and C for the core loop meant that execution was about the same as using C for all the application. Thus Python is a high performance programming language. OK, Python is not going to be used for the computationally intensive part, but it can be the coordination language.

Skills Matter videoed the session, see here.

Groovy & Grails eXchange 2011 session

Groovy and Grails eXchange 2011 is as good, if not better, than previous years. The evolution of Groovy towards 2.0.0, and the imminent release of Grails 2.0.0 has resulted in an increased energy in the Groovy and Grails community. I suspect this is founded on the more positive energy in the Java community since Java 7 came out and the timetable for future Java releases published.

GPars is an integral part of the Groovy and Grails, and increasingly Java, communities, as it allows folk to harness the increasing parallelism of computers using Groovy and Java. I ran a session "Just keep passing the messages" yesterday 2011-12-08T16:30. The slides were a minor variant on the ones I used for JAX London, but the use of them was very different and in fact I only used about 25% of them.

Most of the audience were not familiar with actors, dataflows, Communicating Sequential Processes (CSP), and data parallelism. Everyone did appreciate though that the question "Is Java an object oriented language?" was actually a deep and non-trivial one. So I skipped a lot of the ranting and sermonizing and skipped straight to giving a summary view of the various models and showed some GPars code - though I did retain my ranting against shared-memory multi- threading as an application level technique. I even managed to run some it to show how GPars really does lead to parallelism, and how Groovy is slow, but this doesn't matter as long as the computationally intensive tight loop is in Java. Groovy/GPars for coordination of concurrency, Java/GPars for grunt computation. Yes GPars does have a Java API!

The example I used my standard example of using quadrature to approximate the value of π. Even though I have used it for a while people still report that it remains a good example since it is small relatively easy to comprehend and allows examples to be comprehensible. So it works! All the code is available in a Bazaar branch at Feel free to branch, play, and report data back.

Skills Matter videoed the session, you can find it here.

Groovy & Grails eXchange 2011

End of this week (2011-12-08 and 2011-12-09) is the Groovy & Grails eXchange 2011 being held at Skills Matter. Definitely a case of "Be there, or be square" - or perhaps that should be "if you are not there you cannot be groovy", or some such weakly humorous play on 1960s lingo. Kick off is 08:30-ish, so that'll be 08:30:01 then.

Sadly the conference is two track and I want to go to all of the sessions. I therefore need a volunteer to be my proxy at the sessions I am not actually at. This is especially important at 2011-12-08T16:15 when I present my session "Just Keep Passing the Messages ".

LJC Unconference 2011

120 people turned up yesterday (yes Saturday) for the London Java Community (LJC) annual unconference. I had intended to be a non-presenting delegate. However when it came time to propose sessions, I could not resist proposing a lightning talk on GPars and a group discussion on "Parallelism on the JVM".

I quickly put some slides together for the lightning talk, they are to be found here. I thought the talk went well, certainly people came up during the lunch break to discuss various things about parallelism ion the JVM generally and GPars in particular.

In the end my proposal for a discussion meeting and a proposal for a Q&A panel session got merged, so I found myself on the panel. The natural direction given the members of the panel was parallelism so that seemed fine. I thought the discussion worked well.

The conference was excellent. All the session I went to were great. Well done the team for putting on such a good event.

Democracy - The Opiate of the Masses

Tomorrow being the 90th anniversary of the British Legion Poppy Appeal, the UK having troops in Afghanistan, Afghanistan growing most of the world's poppies for the drug trade, one of which is opium, and having been exposed to the appalling sight of parliament in action yesterday, it struck me that the political classes really are putting one over on the electorate. Probably everywhere but certainly in the UK.

The pathetic posturing, ranting, and petty point scoring on both sides of this verbal sparring, were awful enough. I am guessing this is what 19th century school and university debating was like - preparing the boys of the rich and famous to take on the role of leadership and governance. What was really saddening though was that the two principles in yesterday's events were women. Instead of evolving politics so as to be more sane, these women have descended into the worst pit of puerile behaviour aimed at creating good television ratings that passes itself of as politics in this country.

So rather than bringing a new form of politics, the push to have more women in parliament (in and of itself a good thing, there should be 50% female and 50% male MPs) has reduced these female MPs to the same stereotype of a 19th century male MP as the men continue to adopt. An opportunity seriously missed.

I have no idea what can be tried next to bring a more constructive politics, our combative system is about destruction not about construction - going to war appears to be more important to our politicians than having an efficacious health system for all the people.

It has been said that democracy is a bad system, but it is better than all the others that have been tried. If what we in the UK have today is democracy, please offer me something new that hasn't been tried yet.

11/11/11 aka 2011-11-11

Lots of people appear to be getting very excited about tomorrow being 11/11/11 as being something special. Well as 11/11/11, rather than the more correct 2011-11-11, it is a special pattern. But what is really special is that this is the 90th anniversary of Remembrance Day. 11th November is Armistice Day every year, and every year we should wear a poppy as symbol of remembering the carnage and horror of war, and of the mutilation and death suffered by innocent people and combatants. Even FIFA have relented in recognition of what it means to remember on Remembrance Day. Do it. You know when - 2011-11-11T11:00+00:00.

Python is a High Performance Programming Language

I have just signed up to do an evening session on 2012-01-31 at Skills Matter entitled "Python is a High Performance Programming Language". See here for the Skills Matter advert and sign up page. Don't let the Skills Matter short bio let you believe I only work with Groovy and GPars, Python rocks.

Also don't be concerned that Skills Matter categorize Python sometimes under .NET and sometimes with Scala and F#. This is because they are just putting together a Python training activity and so there isn't yet a proper silo for it in their portfolio. If people take up their newly established Python training activity this will change. cf. this advert

JAXLondon 2011 - Some reactions

I only went to 15 sessions of the total of 40, but given that Day 1 had five tracks and Day 2 had four tracks, I think it was good going to be in a session at every slot. Sadly though there were at least 10 other sessions I would like to have been at.

The four keynotes were reasonable, with a nice mix of motivational aspects and informative aspects. Nothing really stood out though, except perhaps that in Simon Ritter's summary of the road map for Java, JavaFX on Linux is not due till half way through 2013, which shows how much the JavaFX team and Oracle care about being truly multi-platform.

Given my main interest is concurrency and parallelism, I took in all the session related to that topic, along with the Java 8, 9, 10, . . . summaries. I didn't hit the Android track.

Of course I have to mention my session: "Just Keep Passing the Messages", slides here. This was really a rant against unthinking use of shared-memory multi- threading as an applications programming technique, and a plea for applications development folk to learn about and use higher level models such as actors, dataflow, communicating sequential processes (CSP). I plugged GPars as a framework that Java and Groovy programmers can use now to do all this, so they don't have to wait.

All the other 10 sessions were good, worth attending, and I enjoyed them. The three "stand out" sessions for me though (other than mine :-) were "An Introduction to Neo4j (and Doctor Who)" by Ian Robinson, "JavaFX 2.0: Great Interface in Java" by Simon Ritter, and "Understanding the Disruptor, a Beginner's Guide to Hardcore Concurrency" by Trisha Gee and Mike Barker.

Ian Robinson managed to educate everyone attending in the subtleties of studying Doctor Who, including retcons, whilst really showing that Neo4j is really a unique form of database management system. He focused mainly on daleks, which was fine as they are clearly a common enemy! Ian mentioned that the daleks first appeared in 1963-4, which came as a bit of a shock, as I remember watching those episodes at a friend's house the first time they were shown.

Simon Ritter's presentation of JavaFX 2.0 showed for me that it was the right decision by Oracle to drop JavaFX as a purely script based system and to transform it into a Java API. This is not because I want to code UIs in Java, but because it makes it an open system that works well as an integral part of the JRE. Simon's Java examples were fun, and worked well, but showed that Java is not the right language to actually write UIs with. I will be using Groovy most likely. The point is that there is not one fixed language to write JavaFX 2.0, and soon JavaFX 3.0, UIs with. JavaFX 2.0 seems a splendid successor to AWT and Swing. But of course AWT/Swing UIs can incorporate JavaFX bits, so people can use evolutionary rather than revolutionary development. Personally I will just dive straight into JavaFX 2.0, but only when the Linux version is released so that UIs can be platform independent: Windows, Mac OS X, Solaris, and Linux.

Trisha Gee and Mike Barker's session stood out since above all it showed how to do some real science when engineering a solution to a problem. Their problem is to process vast numbers of messages with various transformations of data needed. They showed, via experimental evidence, that standard approaches to concurrency and parallelism we insufficient to the task. Indeed employing parallelism made things slower for their problem compared to a simple single threaded solution due to all the overheads associated with the concurrency and parallelism tools. Here we are not just talking of Java and JVM overheads we are talking of JIT generated assembly language and processor cache line management. I am used to C++ folk worrying about cache lines, it was inspiring to have Java folk seriously worrying about these things entirely appropriately. They then showed how they had analysed various data structures, reasoning with the Java memory model, and experiments probing the JIT code generation, to write a lock free ring buffer that is the data structure at the heart of the Disruptor. Opinion not necessary, the experimental data shows they have been massively successful.

I will be submitting a session proposal to JAXLondon 2012.

Copyright © 2017 Russel Winder -