Well Quite

Reflections on the ICFP Programming Contest 2008

Mon, d Aug 2008 00:00:00 UTC

In 2007, Tristan and I decided to enter the ICFP Programming Contest. We turned up at the right time, downloaded and read the spec, and promptly gave up. We instead spent the weekend hacking on a game we were writing.

In 2008, Tristan and I decided to enter the . This time, things would be different. We did some practise! We spent 12 hours straight on the 2005 contest (Cops and Robbers) and then did a 24 hour (with sleep) session on the 2004 contest (Ants). We were pretty pleased with how we did on those and went into the 2008 contest with a certain amount of confidence.

To cut a very long story short, we will have done badly, very badly. The results aren't out yet, but we know which way this will have gone. However, it was immensely fun, and we will be back next year to try and avoid coming last again!

So, being in the UK, the contest started at 8pm on the Friday. Our plan was to get all the basic infrastructure up before we went to bed as it's pretty straightforward and you don't have to think too hard. We used the same basic state machine pattern that we'd developed for the Cops-and-robbers contest and used Lazy ByteString to read off the network socket lazily - I really do think this lazy input pattern is lovely, though I can see how it's a real PITA to deal with errors. But we ignored errors which turned out never to be an issue anyway. We got to bed at about 2am.

Saturday morning came and we both charged into the office, brimming with ideas. We spent about 4 hours discussing and arguing about what we should do. We both agreed that the only way to win would be to move fast, which means that our route planning would have to be excellent. And so that's all we focussed on. We wrote a lot of code (over 3000 lines of Haskell in 72 hours between the 2 of us) and the vast majority of that was on route finding. Eventually, we realised that what we'd forgotten to do was to think about how to move the robot.

You see, in both of the contests that we'd looked at previously, the setup was that you could pretty much move arbitrarily: if you told the robber to go somewhere, he would do so, no questions asked. Whereas this martian rover did not behave in the same way. It could be told to accelerate, brake, roll, turn left or right, but it wouldn't accept orders to go to a particular coordinate, and it can't even maintain a constant speed, other than not moving at all or moving as fast as possible. And we rather forgot to think about the consequences of this. So at the end, we were able to produce some nice routes, but the rover wasn't really very good at following them.

So we used a quad tree, which sort of worked, though it's not perfect. Quad trees and oct trees are fine for storing points, but not as great for storing areas, which were the boulders and craters. But I kind of mashed through that so it basically worked. We then took the quad tree and turned it into a graph. Now we didn't really discuss this, but I think we should have spent some time trying to work out the best way to do this, because without thinking about the consequences too much, we just too the vectors of the edges of the leaves of the quad tree to be the edges of the graph (actually, that's not quite true. Tris then added lots of other edges so that the nodes on the boundary of a quad tree leaf were almost fully connected within that leaf. Or something like that), which I'm not sure is the right thing to do. And then when we had a graph, we ran shortest path on it, with some extra heuristics.

Which sort of worked. Except that I wrote some very complex heuristics, which would try to find a path across a region even if there were boulders in the region. And that maths turned out to be very expensive (though I may have just been doing it wrong), which very quickly meant that as soon as the quad tree got bigish, there were so many paths to consider and so much maths to do, that the shortest path algorithms would take far too long to complete, we'd loose sync with the rover, and it would all end badly. So I hacked bits out to cut the maths down, the rover sort of gained an ability to drive, and it was all pretty much a disaster. Still goood honest fun!

So below you have a screenshot from our GUI. The left hand side shows the quad tree and the chosen path and the rover and its direction. The right hand side shows the graph which was used for the shortest path algorithm.

What is the point?

Sun, d Jul 2008 00:00:00 UTC

Yesterday, I got a paper rejected from the Haskell Symposium 2008, and I'm going to talk about the reviews I got. I realise this is highly unprofessional, but at this stage I really don't care, especially as in my opinion, the behaviour of some of the reviewers is also highly unprofessional. Also, this is the "calm" version of this rant: fortunately a friend came over yesterday and we went out for a drink or two which stopped me writing this yesterday. Finally, I'm not trying to take anything away from the authors who did get papers accepted, or the work they have done. My complaints are very specifically about the process that takes place though, perhaps unsurprisingly, I don't really have many ideas about how it can be improved.

To every system, every activity, there is a game to play, and to succeed, you must learn to play the game. The British Education system is an excellent example of this: to succeed you don't have to be bright, you don't have to put in any effort, you just have to learn to regurgitate facts as the exams will never actually require you to think. The same can be said for almost all exams I've taken at university. The problem that I increasingly see with the academic game of "getting papers published" is that the rules change far too frequently and actually hinder research and progress.

My understanding of how a conference or workshop or symposium are run is as follows:

A programme committee is formed of, maybe a dozen people. These should collectively have an interest spanning pretty much everything that the conference aims to cover.
Papers are submitted.
Each member of the committee selects which papers they wish to review. They must declare conflicts of interest and each paper typically gets about three reviewers. But, there will often be a load of papers left over that too few committee members are interested in. For whatever reason, the authors thought it was appropriate to submit the paper to this particular conference, but there would seem to be not enough on the committee who are interested in reviewing these papers. It's basically up to the programme chair to get these papers sufficiently reviewed by someone.
The reviewers may well do the reviews. They may farm the reviews out to PhD students or research assistants if they're think that the student or assistant actually has a better current knowledge of the area about which the paper is written than they do.
Reviewers then submit their reviews. These normally have a "score" indicating what the reviewer thought of the paper, and a "confidence" which indicates how seriously the reviewer thinks their review should be taken. Here, the papers left on the pile which no one wanted to review could well end up with three reviews, all done by people who readily accept they are not confident of their own knowledge of this particular area.
Then the programme committee meet. Papers which were slammed by everyone typically don't get discussed and get rejected. Papers which were raved about by everyone don't get discussed, and get accepted. The papers remaining get discussed and somehow some get accepted, up to a limit of how many papers can be presented in the time allowed at the conference.
The reviews get sent back to the authors. These reviews are anonymous and sometimes the "scores" and "confidences" get sent back and sometimes they don't.

There are variations on this, and I've never actually been involved in this process other than being an author. However, I'm lead to believe that this is basically what happens.

So, what does this process mean for authors? Well, there are several things to consider. Firstly, no one actually wants to do reviews. They take time away from your own research and people are just doing them to remain, or become, well known. It's also good publicity for the conference if the programme committee is full of distinguished and well known academics. Programme chairs often choose to organise conferences because they want a promotion and have to demonstrate that they have run conferences and are an international figure. Sure, I'm being cynical and probably unfair in many cases. But this is undeniably sometimes the case. Secondly, reviews can get left to the last minute. If a reviewer has to produce reviews of 10 papers by tomorrow then these reviews will be done quickly. They will often be farmed out to PhD students and RAs who will also be under pressure to get the review done quickly. Furthermore, if your paper is in the pile that no one really wanted to review then the review will certainly be a rush job.

So the ideal situation is to have your paper reviewed by people who are really interested in your area and who are organised and will put the time in to do a decent job. Fortunately for the reviewers, even if they do a really shoddy job, they won't be found out because the reviews go back to the authors anonymously.

Now let's say that your paper is on the pile which no one really wants to review. Your best bet here is to produce a trivial paper - something with almost no content. The reason is that if you start producing anything even vaguely complicated, the resulting rushed and uninterested reviewer will hate you because they will realise that to do a decent job of reviewing the paper will take time and effort that they really can't be arsed to expend. Whereas, if you produce something trivial then they will understand it easily, it won't produce any surprises for them, hopefully they won't have to read anything you cited and they'll be able to top and tail the paper quickly, with a minimum of effort and fuss and still have a decent knowledge of what you were trying to say.

Thus to win this game, plan in advance, for as far in the future as you possibly can. Work out which conferences you are going to submit to and look at their programme committees. Then look at what the members of the programme committees are researching and completely abandon any hope that you can do research on what you want to do, especially if it doesn't correlate perfectly with the interests of the programme committee. Oh and make sure that your topic doesn't suddenly go out of fashion, otherwise you will never get any subsequent publications. It helps if your supervisor or co-authors are widely respected members of whichever community you're working in.

Now I got three reviews back, anonymously, without scores. They paint a very telling story. The first review is excellent. I have never received such a review nor have I ever expected to. The guy has obviously thoroughly read the paper. He has also been to my website and read the tutorials. He has downloaded the software, installed it and used it. By my reckoning, he must have spent at least six hours doing this. It is incredible - as I say, I would never expect anyone to put that much effort in. What I surmise from this is that he wanted to review the paper: he clearly is interested in it and picked it and put a huge amount of effort in. Sadly for me, he then admits that he's sceptical about the value of Session Types in the first place (so it's difficult to see this as being an objective unbiased review, though given the effort he's gone to, he's clearly tried very hard) and then he repeats issues which I have discussed myself in the evaluation, about how error messages are huge and very difficult to make sense of as criticism of the work. And indeed it is - it significantly makes it harder to use the library given this issue. However, he basically does end up admitting that, given the way I have written the library, this is unavoidable and actually demands programmatic control of the errors coming back from GHC, rather than a series of modifications to the library. He suggests that this work could be published as motivation for making such changes to GHC. So he doesn't really like the work, he's sceptical of the value Session Types add and he quite justifiably questions the usability of the library (though oddly not commenting on any of the proposals I make in the paper for solving the error message problem). Overall though, I simply can't have anything but awe for the amount of work and time he has invested in the review. I have absolutely no issue with being endlessly rejected if reviewers go to this much effort. It is simply unfortunate that his default position on Session Types is one of scepticism.

The second review, by comparison is a complete joke. I don't believe the reviewer read past page 4, with the possible exception of additionally reading the conclusion. I question whether this guy knows anything about Haskell at all or left himself more than 5 minutes in which to review the paper. Typically when you do a review, you start by giving a description of what the paper is about, in order to demonstrate that you read the paper. In this review, even this description is wrong:

The paper presents a library that implements session types as a Haskell DSL.

Wrong. A DSL embedded within Haskell is used. And it is used to define a session type. The rest of the library which allows you to implement a given session type has nothing further to do with the DSL. The second paragraph is equally brilliant:

Unfortunately, I find the paper practically impossible to follow. For the most part, this is because it uses a large number of combinators which are never really introduced and explained. In particular, although the paper is about types it doesn't provide any type signatures. This makes it impossible to understand if and how the goal of type-safe communication is achieved. Here are just some of the questions that the paper doesn't seem to answer...

So in the first sentence he admits he certainly hasn't understood and probably hasn't read the paper. He is very correct in the third sentence: I don't have any type signatures in the paper. This is because they are huge, absolutely enormous. If I put the type signatures in then I would have about 3 of the 12 pages permitted left to describe the work. Thus sentence 4 is ridiculous: there is simply no way that adding type signatures would make it easier to understand. Go look up the type signatures for doing subtraction on numbers in the type system, it's not trivial; and that's a simple case for my library: the type signatures in my library are typically over ten lines long. And the use of seem in sentence 5 further reinforces the notion that he hasn't read the paper. He then goes on and raises six questions, all of which come from work discussed before page 4, and all of which are addressed within the paper. Some of them are only fleetingly covered (due to space constraints), but they are all covered. I particularly love his first question: Is a channel associated with a session type? Looking at page 2 of the paper, I write:

Having specified a session type, that session type can then be used to parameterise the type of a communication channel, which restricts operations involving that communication channel to those specified by the session type.

So he gave up before page 2. Good job. At no point does he refer to anything that comes after page 4.

Let's take the first two sentences of his second paragraph and contrast them with the first review. The first reviewer raised no such objections. Not only did the first reviewer read the paper and my tutorial and raise no such objection, but they also used the software to the extent that they demonstrated knowledge of it in their review. This sits a little oddly with the notion that the paper is practically impossible to follow. This is amateur hour at its very peak. Maybe the reviewers should actually compare notes before submitting their reviews because frankly, this is pathetic. The first reviewer has effectively demolished every criticism the second reviewer makes, and demonstrates that the second reviewer didn't care and didn't put any effort into the review. It is utterly obvious that the second reviewer did not pick to review this paper, but rather the paper was left on the pile with not enough volunteered reviewers and so was pushed to the second reviewer. But it's okay, because the reviews are anonymous. So even though I know exactly what happened, and surely the reviewers likewise realise that I will be able to work it out, they have no problem with making these reviews because I can't identify anyone. I would be perfectly happy receiving one review from someone who knows what they're talking about, like the first review, than this shit. And the reason should be obvious: when it comes to the programme committee meeting, the second review is wrong from top to bottom, I can't defend myself against it, but it will completely destroy my chances of being published.

The third review is okay: it's more along the lines of what I've come to expect. It's clearly not the super-human effort that the first review is, but I believe they've read the whole paper and understood it. Sadly, the specific issues they raise with regard to the operation of the library are on the whole addressed in the paper. For example, they query the rather difficult to read notation for session types. Yeah I agree, but I have explained that I can't use do-notation in the paper. They also raise the issue of a lack of compelling example. Now wait a minute! The paper uses an n-queens checker as a running example. This is deliberately trivial in order to keep the code fragments short. It's pretty unlikely that the reviewer would want to be presented with multiple pages of code. I repeatedly state in the paper sentiments such as:

As mentioned in section 2, the bulk of the code of this example is concerned with the communication and very little is actually doing the work of checking for collisions: the detectCollision function is trivial. However, the communication patterns involved here are entirely non-trivial and demonstrate how our Session Type library can be used to tackle such patterns.

In fact, once again, this charge is voided by the first review:

The running example is an implementation of the n-queens check, with one process per queen, which communicate to check that no queen threatens another. It's a trivial example, but the communication pattern is dynamic and fairly complex.

Again, from the paper:

This example problem demonstrates how our library can be used for a much broader class of problems where work is not only farmed out to a number of workers (the queens, in this case) but how the workers must also communicate between themselves in order to complete their work before sending results back to the root process. Note that our example works for any number of workers: the number of queens is not known statically and so this shows how session types can work in the most general case.

What do you want? You want me to enumerate every possible situation where such a pattern is of use? Not to mention all the other communication patterns that can be covered by this library. And finally, in the third review, we get to the nub of the matter:

Much of the code is too intricate to easily read and understand.

Ahh, the displeasure of the reviewer, again, I believe, having the paper foisted upon them and wanting to do a quick job of it. But don't get me wrong, the third review is by no means in the same league of incompetence as defined by the second review. The third reviewer is wrong though: I don't believe there is a code example in the paper which is not explained in English.

All three reviews say that the paper is dense and at least in places hard to follow and I agree with that entirely. But the library is very featureful and is a complex beast, and I only have 12 sides in which to describe it. I give as high a level description of it (in particular, its implementation) as I possibly can without making the whole thing superficial. It's very tricky to write a paper about something this complex and bleeding edge (I really haven't come across anything else that does as much within the type system as I do) and keep it readable. So basically, the conclusion is that this work is simply unpublishable: if I try and give anything other than a totally superficial explanation of it then it becomes too dense and complex, and if I make it lighter and more readable then surely the reviews would come back demanding a more thorough and detailed covering of the work. How can I ever win?

What makes me so angry is that the months of work that went into writing the library, and the weeks of work that went into writing and rewriting the paper can be so easily dismissed by reviewers who really can't be bothered or are just uninterested in the work and rely on the cloak of anonymity or, perhaps more frustratingly, by the fact that the conference which is most suitable for the work and should be the ideal location for this work has a programme committee which is simply the wrong audience for this work.

Anglo Haskell 2008

Mon, d Jul 2008 00:00:00 UTC

Anglo Haskell is a gathering of all people Haskell-related from beginners, to seasoned hackers to academic giants. All and more are welcomed by large fuzzy green lambdas.

Anglo Haskell has happened for the last two years and we see no reason why it should not happen again this year. For the last two years they've tended to have talks on Fridays and then Other Things on the Saturday (including Punting and Group Hacking, some or more of which may have happened in Pubs). We're proposing the same general format this year.

In contrast to the last two years which have been held at MSR Cambridge (UK), we're this year going to hold the event at Imperial College, London. London is probably easier to get to and from (though more tedious to get across) than Cambridge and we hope this will attract people who previously have not been able to get out to Cambridge.

The proposed dates are Friday the 8th and Saturday the 9th of August.

More details are available on the wikipage, including travel directions and all important details about wifi access and so forth. Please feel free to add to this page.

If you're at all interested in coming along then please add your name to the wikipage. If you're interested in giving a talk - on literally anything Haskell related: this is not a solely theory day or solely a practical day; anything goes which is Haskell related - then similarly add yourself to the list of speakers.

Some people have signed up on the wiki page, please add your name if you are able to come or are considering coming along. Also please make use of the wiki page and #anglohaskell irc (freenode.net) channel to arrange where to stay overnight if necessary.

Finally, once again, if you'd like to give a talk then please add your name to the list on the wiki page. We really do need both attendees and speakers to make this event a success.

TiC 2008

Thu, d Jun 2008 00:00:00 UTC

I'm currently attending Trends in Concurrency in Prague which is a summer school, targeting researchers working on concurrency issues. Mainly we've had quite a large number of language tours which are not uninteresting, and each have their own quirks and niceties.

One of the most amusing things I find is how extensive Haskell's influence is now. Fortress and Scala really do seem to have been influenced heavily by Haskell and this seems to work to a greater or lesser extent in each language. Scala does actually support Monads so you can live in that world if you want, and it also has an effective equivalence to Type Classes (though certainly not with functional dependencies, associated types or any of the other magic; in fact I'm not sure whether they're even multi-parameter type classes). Fortress also has clearly been influenced by Haskell, and some of the talk on Monoids over trees reminded me distinctly (though the work is not directly related) of Hinze and Patterson's Finger trees: a simple general-purpose data structure paper and the subsequent presentation Ross Patterson gave at the London HUG.

However, Fortress is still a statement oriented language, and whilst Scala claims to be expression oriented, it's very much like Erlang in this respect, a list of expressions which are guaranteed to be executed in order. In neither language are you required to live under a Monad in order to express a given ordering (yes, I know that's not really what Monads are about, but let this one slide please...) and so they all just feel just a little bit broken. Neither are lazy by default, though Fortress has a means to make expressions lazy (and it also has an effect type system to work out where IO happens - is there some fear of making users actually use and/or understand Monads here?) and Scala allows the type ( => T) to capture a function which is due to emit a value of type T without actually calling the function: in effect allowing you to control laziness.

We also had talks on X10 and a child project (not at IBM) called Habenero which have some neat synchronisation barrier ideas in them called phasers. These allow a barrier to be shared between a dynamically chosen set of threads and for each thread to specify its relationship with the barrier: for example a wait (where the thread will block until the barrier is past), a signal (where the barrier won't be past until the thread sends the signal) or sig-wait (where the thread both has to signal the barrier and wait for the barrier - i.e. a full barrier from openMP). X10 does not seem to be Haskell influenced at all, but two out of three isn't bad. Also, I'm not actually the only one in the audience of just over 50 that's a Haskeller. There are several others here and a good percentage at least claim some functional knowledge. These are clearly not the hoards of unwashed Object-Oriented and Imperative programmers. Overall, really very interesting.

Derelict Sky

Mon, d May 2008 00:00:00 UTC

Derelict sky of fallen clouds, opaque
and egg-white blue.
Looking straight at me, myself
planted in this vision, seeing
nothing, embossed in shadow and dust.

Daylight fading and in the freedom
of darkness I dare to gaze;
the ground beneath me, spreading in.
Gently I tread, then faster I pelt away
from haze, until

I stumble and stagger, fallen
into the mist, resting up
against the walls of the cage
I have furnished.

So I get in a rage and I
get in a stupor and I
throw up the chairs and the sofa and table
'til eventually, with the sun behind
and in front and above,
the clouds in the sky,
looking straight at me

Myself.

Tutorials on Session Types

Tue, d Mar 2008 00:00:00 UTC

Recently I've been making much progress on my implementation of Session Types in Haskell and so due to popular demand I've written a series of tutorials on how to use my library.

About a Horn, Part 2

Tue, d Jan 2008 00:00:00 UTC

I started playing the Horn in September 1991, on an Anborg Como Single F. A few years later, though I'm not quite sure exactly when, I moved up to a Boosey and Hawkes 400 Compensating F/B-flat (yes, that Horn that everyone had). A few years after that I moved to a Holton 178 (full double F/B-flat), which remains my Horn to the day. Again, I'm not totally sure when I got it, but I reckon I must have been playing it for about eight years.

I'm tempted at this point to write about how Holtons are typically used by students and aren't really seen being played by pros, but really that's completely irrelevant. Plus it may well not be true - Holton, like Conn, are an American manufacturer and may be more widely used across the pond. Plus I'm not a pro, nor will ever be.

Anyway, over the eight years that I've been playing her, Henrietta and I have made some nice noises and played some memorable concerts. We've also cocked a few things up from time to time, though she swears it's my fault... I have however increasingly noticed differences in sound between Henrietta and all the Paxmans that are so dominant in London and certain deficiencies in Henrietta: particular passages that I have to work at overly hard which I really don't think I should have to. For example, the Mozart Rondo in E-flat KV 371, the phrase starting at the end of bars 24 and 141. Here, the slurring down to the G in each set is remarkably easy to miss. Also, Mozart, KV 495 (the "fourth" concerto), the runs up to top C (bars 52, 70, 185) are really difficult to make speak cleanly on Henrietta. Also, certain notes are just "bad", a high A, for example does not speak cleanly, and is very wide, where as the B-flat above it is really nice. The same is true of third-space C which is wide and difficult to centre, whilst the D above it is very nice and predictable. I suspect that inconsistencies such as these have caused a number of issues over the years!

So I hatched a plan. At the end of October 2007, the British Horn Society held their annual "Horn Day" and this year it was at the Royal Academy of Music. Now, I've been to these things before, though some time ago, and regional ones. The main national one always has a number of Horn manufacturers there and so I went along and grabbed some Horns and tried them out. And I didn't really like any of them. I'd forgotten to take any music with me so I picked them up, played a few notes and came to the conclusion that they were French Horns. That was about all I could conclude.

I was then really too busy to entertain any further ideas until the new year (2008). However, just before Christmas, I spent a couple of hours in Paxman's, playing some of their Horns. I took music with me, and eventually came to the conclusion that they were Horns and that I didn't like their gold brass 25. However, I was starting to realise that this testing and comparing Horns was much harder than I'd thought it would be. 2008 arrived and with it came a second hand Engelbert Schmid, in gold brass with three bells to choose between - a plain yellow, a plain gold, and a gold with garland. I have had this Horn for nearly four weeks now and I've rather grown to like it. I also went back to Paxman's and got a yellow brass 20M on approval which is about to go back.

Obviously, the following is totally my own opinion. People are physically built differently and have different strengths and weaknesses. Personally, I find the Paxman very uncomfortable to hold (I have very large hands and find the finger hook both several inches in the wrong place and very painful), I dislike how far away the spatulas are and I dislike the length of travel of the valve levers. I also find the resistance of the Horn inconsistent - adding length seems to affect the Horn more than with the Schmid. Further, whilst the high end is nice, the low end I find significantly less focussed than the Schmid. Now, once again, this is my own opinion. There are many professional Horn players playing on Paxman 20s and so you could easily wonder what the hell I'm moaning about. Also you actually have to take into account what is available "now". There are waiting lists for new Paxmans. People have suggested that I try a Paxman 25 and I did before Christmas, but there are none available now. Second hand Schmids are even rarer: what if I wait for a Paxman 25 to turn up and then find I don't like it as much as the Schmid but by that point the Schmid has gone? Such issues make making a perfect comparison very difficult.

The Schmid is very light. Staggeringly so. Even just comparing the bells from the Paxman and the Schmid (and the Schmid bell is taller - it joins on to the Horn further up the Horn, if you see what I mean), the Schmid bell is much lighter. This is, I believe, a consequence of the fact that the Schmid bell is entirely hand hammered, and only machine spun at the last minute. My understanding is that the Paxman bells are entirely machine spun. The Schmid uses thinner metal and is thus lighter. Now one of the best consequences of this is how much feedback you get from the Horn - you can really feel the Horn vibrate underneath you - the Schmid is vastly more alive than Henrietta my Holton and more alive than the Paxman too. The obvious analogy would be between a Formula One car where every single unnecessary gram has been removed and normal Sports car which has enough boot space to take a set of golf clubs. On the other hand, I've never driven either and, coming from a computing background, I'm rather aware of how bad most analogies really are.

A lot of people seem to rave about the valves on Schmids. They certainly have very little travel and are fast and light, but in my experience, if you oil daily almost any valve, it goes quickly. I've certainly kept the valves on Henrietta running faster than many of my friends who play Paxmans, and I'm sure that's completely down to regular oiling. No, for me, the most staggering difference is how alive the instrument feels. In comparison to Henrietta, the resistance of the instrument is both much less and more predictable. The bass end has much more tone and the notes are much better centred. Plus, Henrietta is in yellow brass and the Schmid is in gold brass. I find, as many do, that the gold brass gives a much warmer tone whilst playing quietly, and when pushed resists going razzy much much longer than the yellow brass. Plus, I can play about twice as loud as I can with Henrietta: almost to the point where I can hurt my right ear.

So I've also learnt some things about testing Horns. Firstly, your opinion on day one is almost worthless. You're probably used to playing in a certain room with a certain acoustic. Going into a shop and trying to make comparisons is not going to work out well; too much has changed. (On the other hand, the UK Schmid distributer came up and spent an hour with me in my usual practise room and thus we were able to discard many of the bell options quickly and accurately.) Secondly, and this really took me about a week to figure out, comparing Horns does not mean practising. When playing, or practising, I certainly just concentrate on the notes, the dots and everything else on the page, to the extent that I'm not actually really listening to myself particularly critically. I'll be very aware of splits and tuning and dynamics, but I'll be less aware of really how the Horn is feeling or what it's doing under me. So I've found that playing things that I know really well, to the point of boredom, where you can stop thinking about the notes and think about the Horns instead is best. Also, if you're trying to test certain parts of the Horns, work in short phrases. For example, studies like Kopprash 13, Derek Bourgeois 4, or things like Cooke Rondo in B-flat, or Franz Strauss Nocturno work well when you pull them apart and just do single phrases on each Horn, for testing speed of response, centring of notes, high and low range, dynamic response etc etc. Just playing a few pieces over on each Horn really never gave me enough feedback - I'd get to the end of a piece and think "Hmm, that went okay, but there were bits that went better on the other Horn and bits that went better on this Horn". Useful.

I found recording myself revealing, though I have very little equipment and so it was limited to quieter passages. Nevertheless, it gave me a different point of view and allowed me to hear things in my playing that I don't normally hear at all. I also persuaded a friend to come and listen blind to me playing. The ease with which he could identify when I was playing Henrietta was quite startling, and he made me think about aspects of tone colour more than I would have otherwise, mainly as he decided he preferred the gold brass with garland bell - rather throwing a spanner in the works!

So in conclusion, it's been fun. Turning up at a rehearsal with 3 Horns and 5 bells is always a laugh and it's interesting how there is no Horn which is perfect: they're all a series of tradeoffs. It's also been very hard to be objective, to really concentrate on what the Horn is actually doing beneath me and to try to work out why I prefer one thing to another. I'm still not totally decided on which bell for the Schmid, though it's looking like the plain gold bell is the most flexible and versatile. Now I just need to rob a few banks, and come up with a name...

About a Horn, Part 1

Fri, d Jan 2008 00:00:00 UTC

This is really not the post I wanted to write. But this is necessary information to understand the upcoming posts.

As many of you will know, and should be evident by other posts on here, I play the French Horn. The French Horn really is a family of instruments and is really quite unique in this respect, I believe. So some brief history is needed, along with an explanation of some of the standard types of Horns available.

The French Horn was originally a hunting Horn: an instrument which was worn around the body of a horseman. It had no valves and this meant that it could only play notes on the natural harmonic series dictated by the length of the instrument. The actual truth is a little more complex, and I'm not totally confident in my own understanding so I'll leave that out. Because the Horn can only play notes within a particular harmonic series, when it was used in a non-hunting context, the composer would indicate how long the instrument should be so that the player could create the right notes. This is why music throughout the Baroque and Classical periods will indicate "Horn in C", "Horn in E-flat", "Horn in Something" where Something is a key. As a piece modulates, the composer will often ask the player to change key, during the piece. This often takes some time - removing certain tubing and replacing it with different lengths. This all but eliminates the possibility of asking the Horn player to play any chromatic passage.

Around the start of the 19th century, some clever sod invented valves. This allows the player to change the length of the Horn very very quickly, without doing any plumbing at all. Slowly, people settled on a "Horn in F" - basically, 12-ft long with three valves which can be used in combination to adjust the length of the Horn from "Horn in F" right down to "Horn in B-natural" - about 15-ft long, in semi-tone steps. You may be wondering about the missing keys - F-sharp up to B-flat - these overlap with notes available from the accessible keys and so you can in fact play all the notes - except in extremis: right at the lower end of the Horn there are gaps which can not easily be sounded. Fortunately, it's very seldom that a player is required to play that low.

Now the idea was that composers should stop thinking about the harmonic series and should just write chromatically for "Horn in F". Leave it up to the Horn player to work out which fingering / which valves are actually needed for a particular note. For example, if the composer wanted the Horn to sound a G, below middle C, they should just write D (having adjusted by a fifth for the "Horn in F" bit) and then the Horn player will see that D and depress the first valve, lowering the Horn from "Horn in F" to "Horn in E-flat" which contains, in its harmonic series, the desired G (though the Horn player doesn't consciously think this. They just think, "it's a D").

However, some composers didn't get the message, and in some cases continued thinking for the Horn player, asking them to change to "Horn in E-flat" and then writing an E (following from the above example). It achieves the same effect, but in increasingly requires the Horn player to mentally rewrite the piece to "Horn in F" and then using the correct fingering. In fact, even in the 20th century, you had composers such as Richard Strauss writing his second Horn Concerto (1943) for "Horn in E-flat". I doubt anyone has ever played in on a "Horn in E-flat": almost without doubt, everyone playing it will be using a standard "Horn in F" and performing the necessary mental transposition to select the correct fingering and make the right notes sound.

So back to my original point about the family of instruments that are known as French Horns. The following are all modern French Horns:

Single Horn in F. This is what I described above: the basic length is around 12-ft, and it has three valves that allow it to achieve the harmonic series in the keys, F, E, E-flat, D, D-flat, C and B. This is the standard starter instrument and is what I first learnt on. A good "Single F" can often be only a few hundred pounds and the instrument is reasonably light.
Single Horn in B-flat. Because as you try and play higher, the harmonics get closer and closer together, it becomes much easier to miss the desired note and instead play a nearby harmonic. You will immediately know when this happens and it's very annoying. If you shorten the Horn then you widen the gap between the harmonics again, making it harder to hit the wrong note; the Horn feels more secure. A Horn in B-flat is 9-ft long: literally twice the length of a standard Trumpet in B-flat, and a 4th higher than the standard Horn in F. Again, it will have 3 valves which will allow it to achieve 7 keys in total, descending in semitones from B-flat through to E.
Double Horn in F/B-flat. This is the standard Horn and what the vast majority of players will use. The instrument is a combination of both the Single Horn in F and the Single Horn in B-flat. It has one bell and one mouthpipe, but a fourth valve allows the player to select whether the B-flat side or the F side of the instrument is in use. Typically, the player will use the B-flat side almost exclusively for higher notes and the F side for lower notes, though depending on almost anything, virtually anything is possible. Almost every note will have at least two different fingerings - some of which will offer a more in-tune note or a note which is harder to miss or a fingering pattern which is easier to achieve in a fast passage.
Alto Horn in B-flat/F. If the player is going to be playing a lot of very high notes, the security of the B-flat side is often not enough. So therefore halve the F-side to a 6-ft F-side which is now shorter than the B-flat side, making the really high notes much more secure. Note that I say secure. I do not mean easier. The source of all sound on a brass instruments in the player's lips. Regardless of the length of the instrument, the player must still make the vibrations in the lips at the correct pitch. A shorter instrument simply places the harmonics available further apart, reducing the risk that you mistakenly, given slight inaccuracies in the vibrations coming from the player's lips, play the wrong harmonic. Other than the halved F-side, the Alto is the same setup as the Double. With the decreasing length of the Horn, the ability to play low notes well deteriorates dramatically. This is really why the Alto is not that common: there are just too many pieces that demand the Horn player play reasonably low notes which are not in tune or sound pleasant on an Alto.
Triple Horn in F/B-flat/F-alto. Yes, you saw it coming. All three instruments offering a tremendous range. It'll have at least 5, if not 6 valves and normally 5 valve levers - two of which will be operated by the thumb. Um, yeah. There are a number of problems with triples. Firstly, you have a lot of tubing, which makes them very heavy. Secondly, you really don't want the bore of the tubing (i.e. its diameter) to be the same for all three instruments: the F-alto side really should be a smaller bore in order to offer a similar resistance to the player across all three sides of the instrument. This often ends up forcing a valve very close to the mouth-piece end of the mouthpipe, which then often demands that the main tuning adjustment is directly after the mouthpiece. This then means that as you tune your Horn, the Horn moves further away or closer to the player. Oh, and they're very expensive too, simply because they demand both more material and much more labour than a standard Double.
Double Descant in F/B-flat. Even higher. 6-ft F-side and 4.5-ft B-flat side. I.e. the B-flat side is actually the same as a Trumpet. I don't think I've ever seen one of these in the flesh. They will only be used in very certain circumstances, for example Baroque music was often written for much shorter Horns and is in fact often played on Trumpets these days as it's so screamingly high.
There are other possibilites available too (I've not mentioned anything about "compensating" Horns). All in all, there are probably about a dozen different "standard" French Horns.

But, and this is finally my point, the composer doesn't care what the player is actually playing on, and, to a certain extent, neither does the player: the player will (almost) always think in terms of a standard Horn in F. The player will know, given a Horn in F part, how they should play any given note. The composer will write for a Horn in F. The player may be using a Single B-flat, but the player will think in terms of Horn in F, and will read the part without applying any mental transposition, but will make the correct vibrations and use the correct fingering such that the desired note will sound through some combination of achieved length and harmonic within that length.

Contrast this with Trumpets, where the composer will still, today write for Trumpet in B-flat, or C or D or whatever. Clarinets in B-flat or A or E-flat (or sometimes C). Flutes, Alto Flutes, Bass Flutes, Piccolo. Even Trombones will be explicitly written for Bass, Tenor and Alto Trombone. Thus the Horn is unique in the number of instruments that are available that are still called French Horns and the fact that the composer has long since given up caring (or in most cases understanding) about what particular type of Horn the player is using.

Konzertstück for four Horns and Orchestra

Wed, d Nov 2007 00:00:00 UTC

As some of you will know, I play the French Horn. It is a fine instrument capable of soaring highs and shattering depths, but there isn't really much concerto repertoire out there for the Horn. Unlike the Piano or Violin, there aren't hundreds or thousands of concertos. There are about seven which are well known and you might get up to 50 if you count everything regardless of quality.

Even, seemingly, wackier than a concerto for Horn is a concerto for four Horns. But Schumann was "up for it". So there's this concerto with four solo parts for four horns and then the usual orchestral parts as well. And I'm playing the second solo part!

The Imperial Sinfonietta orchestra are giving their concert on Friday, 7th December at 8pm in the Great Hall at Imperial, South Kensington. The programme includes the Konzertstück as the second piece in the first half with Shostakovich's mighty and very popular 5th Symphony as the second half.

If you're not otherwise busy, engaged or determined to cause harm to your liver, please come along. Tickets should be available on the door except if we've managed to pre-sellout the concert, which is unlikely. This a fairly rare piece, seldom performed but providing vastly more entertainment than Rach's 2nd Piano Conc., or Bruch's Violin Conc... Be there!

Shared Mutable Memory Must Die

Sat, d Nov 2007 00:00:00 UTC

On Friday I had the opportunity to meet Joe Armstrong who created the Erlang programming language. He was visiting London and popped into LShift to give a talk. It was only meant to be a 15 minuted talk but ended up at a couple of hours; all the better for us! Now I'm pretty big fan of Erlang, though I prefer statically strongly typed languages like Haskell. It is true that you can do things in dynamically strongly typed languages like Erlang that you can't do in statically strongly typed languages but personally I don't think these are necessarily good things and I think the advantages of statically typed languages vastly outweigh any loss of expression. But that's not what I really want to write about now.

I have heard tales of the strangeness of the Grand Old Men of Computing. I guess Joe's probably still a bit young to fit in to that category, but the eccentricities are certainly there for all to see, making for an amusing if at times bemusing talk and general discussion. What I was most happy about is that he reinforced many of my own beliefs about where we're heading, beliefs for which I've received sod all support from those around me at Imperial. Because Joe's out there actually working on these problems day in, day out, he speaks from an experienced and authoritative position which again, makes me feel much better about my own convictions.

The fundamental problem is that most programmers believe in a model of a computer which is just not accurate any more. Languages like C and C++ reinforce this belief in a broken model of computing and the hardware manufacturers have hardly helped as they've really just been throwing more transistors and silicon at the problem like a bandage, trying to patch up the problems and maintain the illusion.

The illusion comes from the idea that multiple CPUs or Cores on a CPU can share data simply by reading and writing values to the same address. This requires a single unified address space (i.e. address x means the same location in memory from the perspective of all CPU cores (yes, ignore page tables and virtual address spaces for the moment please)). Originally, this may not have seemed such a crazy idea: memory used to be very fast with respect to CPU speeds, whereas now it's much much slower. Because it's been getting slower and slower, manufacturers have added caches all over the place. We have caches on hard disks, several on CPUs themselves, various caches that are shared between cores, and some which are private to each core. We have separate caches for instructions and for data. In some cases we even have caches for instructions after they've been decoded by the CPU. There are many caches. And therein lies part of the problem: if you only have one copy of a given piece of data, it might be possible to come to some kind of global consensus about its current value. But as soon as you start duplicating the data into several caches, working out who owns a particular value and how modified values should be combined in order to update the main memory becomes much much harder. So we have Cache Coherency Protocols which try to intercept memory accesses and make sure that multiple caches can't contain updated values for any given address. Sort of.

By not exposing the cache to the programmer, and by trying to maintain this shared mutable memory concept, programmers are forced to resort to locking and similar techniques in order to try to ensure that concurrent modifications to shared data simply don't happen. Modifications to the same set of addresses must not happen concurrently, but sequentially so that the data is mutated in a predictable, safe and intended way. Using locks is, as we all know, inherently dangerous: deadlocks can occur very easily and it's difficult to get the balance right between coarse grained locking which is easier to debug and reason about but may reduce performance by unnecessary locking, and fine grained locking which may allow better performance, but the number of locks makes it much harder to reason about and have and kind of confidence in the correctness of the locking and freedom of deadlocks. In fact, it's simply unwise to ever believe that any non-trivial multi-threaded application is deadlock free. It's really quite unlikely. Furthermore, deadlocks are only one issue arising from the general race conditions inherent in the shared-mutable-state world. Thread scheduling, timing and other issues can all combine with or without locks to result in unintended consequences which are often difficult to track down, repeat, debug and fix.

Perhaps the more significant problem is scalability. If you designed a computer system for a million CPUs and then scaled that design down to one CPU you have the knowledge that as your needs grow, your design will scale up and will work correctly. If you design for one CPU and then try to scale up, you're going to need a lot of bandages and a big sewing kit to sew up all the gaps. The reason why this is perhaps the more significant problem is the direction in which CPU manufacturers are heading. Now AMD and Intel are both thinking that somewhere between 2 and 8 cores would be fine for most desktop users. But for servers, it still seems to be a case of the more, the merrier. So actually considering how you would work with a million CPUs or cores isn't the far-fetched an idea. It's certainly unbelievably short-sighted to think that you can get away with only considering the case for a single core or two. If you design for a million CPUs, you also come to some significant conclusions early on in the process. For example, you realise that it's a very silly idea to pretend that all memory should be equally available to all CPUs at the same time. If you try to do that, then you'll end up with a memory system that is phenomenally slow for all CPUs and fast for none because the memory system will have to have enormous bandwidth to process all the requests from a million CPUs and will potentially suffer horrible performance problems when trying to regulate access to the shared mutable memory.

To expand on this a bit further, Joe pointed out what actually has to happen when you "take a lock". A lock obviously has to be safe by which I mean that if two threads on two different CPUs try to take the same lock at the same time then only one can succeed. Furthermore, a lock is usually just a particular value at a particular location in memory. So if two threads wish to take the same lock, they both have to try to read the value of the lock and update it atomically. CPU instruction sets normally provide a dedicated instruction to do this, but it affects the memory system and often causes lots of work for the cache coherency protocol to deal with. If you have a million CPUs all trying to access the same value, you have something of a problem as all million CPUs will try to issue the instruction to test and set the lock and that will cause the memory system to send the value of the lock to all CPUs and track which CPU got there first (agh, first. That means we've got to place these requests in order somehow. So they actually become sequential, not parallel, and that means that the millionth CPU may be waiting a long time before its request gets serviced) and thus has the right to write back to the lock whilst the others cannot. And when that value is written, the lock is taken, the new updated value will then have to be sent out to the remaining million minus one CPUs so that they can then see that they cannot take the lock. So all but one of the CPUs have stalled waiting for the memory system. If there's much contention for the same addresses, this can get pretty expensive.

If you instead build a memory system where the memory is distributed, local to each CPU, then you can get very very fast access to the local memory. At this point you might consider whether it's worth your while trying to maintain the illusion of a single address space. Whilst there's lots of pressure from software vendors to ensure the single address space remains, there are lots of reasons why I think it will eventually die. Firstly, memory access now becomes irregular: if your thread is running on a given CPU and the addresses it is accessing are local to that CPU then memory access will be very fast. But if it's accessing addresses which are not local to that CPU then memory performance is going to be very slow. When you have only a few hops to get to the desired memory banks, it might be manageable: aggressive caching and pre-fetching might just hold you together. But with a million CPUs, the average number of hops is going to go up a long way. And that's really going to hurt performance.

So what happens if you throw out the single address space? Well firstly, you can make memory accesses go even faster. You can throw out all the cache coherency silicon and you can throw out regulating memory access. And what do you have? Well, if you squint a bit, you have a million CPUs, each with their own, very big addressable cache. And then if you squint a bit more, you suddenly realise this is quite similar to what we already have with, e.g. the Cell CPU and Tilera.

So people then turn around and ask how you can communicate between threads? - it's really quite an essential feature. Well, you have networks, just like in large distributed systems that we have today. A network is sort of in the direction of shared mutable state, but it's vastly safer and more predictable. And so this is why Erlang, and its message-passing concurrency is so obviously the correct solution. Two CPUs can actually send a message to the same destination at the same time and have the messages arrive in some order that does not result in one message being lost. Not true with shared mutable state. Whilst you can use shared mutable state to implement message passing and whilst if you do, you will still need locks (in fact, the normal implementation of Erlang does this on typical consumer computers), firstly, the sections of code which need to be analysed and carefully thought out from a deadlocking-avoidance perspective can be made very small, and secondly, the use of shared mutable state is really only a stop-gap measure. Also, please note that I'm not pretending you can't deadlock in message-passing systems. You can. But it tends to be harder.

If you think about how you'd implement message passing in such a million CPU system, you'd send messages from CPU to CPU directly. You wouldn't go out to some shared mutable memory bank as that would be dog slow. If you look at the design of the Cell or Tilera64, it's easy to see how targeting the various cores directly as the destination of the message would be much much faster. Now at this point you might raise a hand and say, well, if this is all in hardware, you're going to have finite message buffers and other annoying limitations like that. True, you will. There are a couple of things I'd like to point out in return though. Firstly, ethernet has dealt with this issue for a long time. CSMA/CD (ensuring multiple hosts don't try and send on the same wire at the same time), and TCP/IP ensures that messages don't get lost, get buffered and are resent when necessary. And sure, there are still limitations in buffer size - hey, this is the Real Physical World after all, limitations of size will always exist. But the buffers just have to be big enough so that they don't cause issues most of the time. It's an engineering tradeoff. The other point is that you could, if you still have some general shared mutable memory, use that as a larger area to send messages to if the intended target is otherwise swamped with work to do.

And this really puts the final part of the picture in place. Currently, if your computer runs out of memory, it will start using the hard disc to store areas of memory that it thinks haven't been accessed recently - swapping or paging out to disk. This works very well. So if you consider something like the Tilera64, you could imagine that you do the same, but one level up: when your own core-local memory fills up, you evict parts of it out to the general memory. Of course, since the values you've sent out to general memory will only be recalled by you, you still don't need to provide for shared mutable memory: the memory is certainly shared between many CPU cores, but any given address is only ever accessed by a single core.

As ever, the problem here is legacy code. The fact that more interesting CPU designs are starting to appear should be an indication that in the not too distant future, things are going to change. What's likely is that eventually we get a hybrid design where you can put your CPU into different modes: fundamentally whether the CPU-local cache appears as a separate addressable memory space or whether it's the same old transparent caching layer we're used to. Networks on a chip are already here and won't be going. Hopefully, if this trend continues, we shall find that certain warts of the computing industry, such as C, disappear from general use, appearing only in the most specific and suitable corners. Maybe even C++ and Object Orientation in general all but disappear as the assumptions of computing on which they are built become ever slower and unwieldy to maintain.