Well Quite

TiC 2008

Thu, 26 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, 26 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, 25 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, 29 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, 18 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, 28 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, 17 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.

New Site (followup)

Sun, 04 Nov 2007 00:00:00 UTC

I guess even a few months ago, I would not have attempted to write scripts for generating a website in Haskell. I would have succumbed to old habits, reasoning that Perl is the correct language in which to do text manipulation and to just bite the bullet and get on with it. In hindsight, I'm very glad I did attempt to do it in Haskell. I'm left with just three programs, one which takes articles and generates JSON from them, one that takes JSON and generates HTML from them, and one that takes JSON and generates RSS from them. All three are either just under or just over 100 lines of code, and sure, I used as many libraries as I could, but I fail to see how I could have done the same work in less code in Perl.

So a little bit about the structure of this site then. I write text files, where the file name is the computer name of the article, the first line of the file is the human name of the article, and the rest is raw HTML. I maintain a set of files that point at the head of each chain - the blog is a chain as are the other pages linked from the left. Each plain text file is converted to JSON and inserted into the list - it's a double linked list. Time is also added at this point.

The JSON version is then used to generate the full perma-link version by combining with a template, using the Text.HTML.Chunks module I wrote a while ago. Then you just point the RSS builder at the pointers to the head of the chain and it generates RSS for the last ten entries. Pretty simple really. There's a JSON module that I'm very familiar with, and I grabbed an RSS module from hackage which I then edited so that it uses Data.Time rather than the old and broken System.Time module.

To take just an example of the power that becomes available: The JSON files store the date in a human form. This is probably a mistake, but if I did a proper timestamp, I'd then have to deal with that in Javascript which probably wouldn't be pleasant. So, in order to build the RSS, the RSS module I need wants the PubDate as a proper time format, not just a String. So I have to parse it. The problem is that none of the time formatting codes include the English number suffixes: e.g. the nd in 2nd. So, in a normal language, I'd have to write some horrible nested if statement to test for %est, %end, %erd or %eth (%e is the day of month, space padded). But in Haskell, parsing is well known as an action that can fail, so it's wrapped in Maybe. Maybe's also in MonadPlus, so I can simply write:

rebuildDate :: String -> Maybe UTCTime
rebuildDate dateStr
    = msum . map (flip (parseTime dtl) dateStr) $ parsers
    where
      dtl = defaultTimeLocale
      parsers = [ "%A, %B %est, %Y"
                , "%A, %B %end, %Y"
                , "%A, %B %erd, %Y"
                , "%A, %B %eth, %Y"
                ]

Now that is rather beautiful. The first one to succeed will be the one who's result will be returned - that's what msum and MonadPlus gets us. Ok, so if you're not used to Haskell, it might not strike you as being that clear, but let's consider the alternatives.

Haskell, but without the msum:

rebuildDate :: String -> Maybe UTCTime
rebuildDate dateStr
    = case parseTime dtl "%A, %B %est, %Y" dateStr of
        (Just date) -> return date
        Nothing -> case parseTime dtl "%A, %B %end, %Y" dateStr of
                     (Just date) -> return date
                     Nothing -> case parseTime dtl "%A, %B %erd, %Y" of
                                  (Just date) -> return date
                                  Nothing -> parseTime dtl "%A, %B %eth, %Y"
    where
      dtl = defaultTimeLocale

Yep, that's really nice. We've got much more code there and the horrible nested control flow. Let's consider expanding that to twenty different date formats. In fact, this is going to be the same pattern for all normal languages so I won't bother repeating them here. The only difference is that most languages won't force you to deal with the error case, so your code will probably be buggy.

Regular Expressions. The problem with this approach is dealing with everything else in the format string - you don't want to start putting the days of the week (%A) or the full name of the month (%B) in the regular expression. In fact, you don't want to use \d+ for the day of the month either. Nor will \d{,2} do either - both allow values for the day (number) of the month that %e does not (e.g. 99). So the best you could do would be to parse using a date library the "%A, %B %e" and then, if all's okay, drop the next 4 chars and then parse the "%Y". But that accepts strings that should be rejected, so use the regular expression to match on "(st|nd|rd|th), ". And then grab the "%Y".

My point is that lots of people seem to think firstly that Haskell isn't suitable for real world tasks, and secondly, that the things Haskell makes you deal with just get in the way. Hopefully, this has illustrated that the things Haskell makes you deal with are useful things, like errors, and failures, and it actually has rather wonderful machinery to prevent you from forgetting about these things which other languages don't. Any what's more, you can use such stuff to your advantage to write small amounts of very reliable code.

I don't really think that Haskell makes it easier to write simple programs. But it does make it quite a lot harder to write faulty programs.

New Site

Sat, 03 Nov 2007 00:00:00 UTC

Once again, this site has changed. Some things may not yet be working - RSS feeds for example, and some links may be broken too. I got fed up with WordPress, mainly due to the amount of comment spam that was going on. So there are now no comments. If you actually want to comment on something, I'm fairly sure you'll be able to work out how to do that.

Also, I decided that I dislike the amount of computation that goes into producing a single page with WordPress. It strikes me that if you think about the energy use, or just the CPU cycles, regenerating every page without a caching layer for each page request is going to be quite a lot of work. So this one, hand written, is entirely static. I have some programs that I've written (in Haskell, obviously!) that help me generate the HTML from templates (they do a few other things too) but other than that, it's all static. And by using XML HTTP Request (err, AJAX in other words), I cut down further on the volume of data transferred. Yes folks, that's my excuse for gratuitous use of AJAX!

Permalinks are there - just click on the title of each entry. I've made sure this degrades nicely in less feature-rich browsers and I've even tested it in Internet Explorer. Enjoy!

Anything but an iPhone

Tue, 03 Jul 2007 00:00:00 UTC

There are an increasingly large number of people who hate the iPod. Pretty much anyone who really cares about audio quality, or even value for money, or who feel that it's a public duty to inform the world that Apple aren't the only company to make MP3 players fall into this camp. And, the nice thing about being in this camp is that there really are devices out there that are significantly better than the iPod, in terms of features and value for money. One good example is the iRiver Clix 2 (review): no need to use iTunes, a sporting chance of making it work on Linux, decent FM radio, high quality audio output, support for Ogg Vorbis up to Q10, really amazing AMOLED display, arguably a more intuitive interface than the iPod, support for video up to 2Mbps etc etc.

In short, owning such a device gives you the smug feeling that you're somehow better than the brainwashed masses who think that the peak of mobile audio is a black shadow dancing to distorted crap coming out of some of the world's worst earphones (go buy yourself some Ear Canal 'phones instead). On the other hand, there do seem to be people who think that Apple are the only people to make MP3 players; whilst humans are pretty stupid, you have to admire Apple for being able to make people think this: Apple were neither first nor are the best, but, there was a point at which they were the best. Now they're just cashing in.

The iPhone is at a similar point. Having just slugged all the way through Anand's review of the thing, it's pretty clear that there are areas in which this device truly is the best thing out there. It's also pretty obvious that there are a host of missing features and other fairly minor annoyances, such as its tendency to melt your ear when making a phone call (what?! People still use mobile phones to make phone calls?!). I actually find it pretty surprising that other companies haven't preempted the iPhone given they are aware of Apple's history, the religious cult of Job-worshippers, and that there is nothing new that the iPhone does - it's the combination of features, packaging and technologies that makes it work well. Maybe this is just better evidence of how little real thought goes into designing a new consumer device and thus why companies like Apple really are a good thing. Some examples:

Overdoing unused features. The iPhone only has two profiles: noisy and silent. These have a minimum of options, but because there are only two, you can put it on a slider switch on the outside of the device and make it damn easy to switch between the two. How many people actually use more than two? My PEBL has about 6, and the only two I've bothered configuring and hence use are "silent" and "vibrate+ring". Clearly, actually paying attention to the features that people use pays off here as a better interface is achieved.
Refusing to see the relationship between different applications on PC platform and mobile. Apple, and the iPhone, have made SMS seem like IM. This is a very good thing, only takes a few moments to realise why and significantly improves the usability of the device. Effectively, we finally have threading for SMS, based on sender/receiver. Now that it's been done once, I can't believe any mobile won't do this - it's such a no-brainer.

So, how long before we actually get something that's better? Dunno. Will there be stuff coming out that's better. Definitely. On the other hand, given that the network operators have a big say in what phones are supported, it will require more effort than beating the iPod. I would really love to see the openmoko guys produce iPhone beaters, but it's more likely that bigger manufacturers will have to do it. The other factor is that, I would guess, developing and releasing an MP3 player is a lot cheaper and easier than developing a whole phone.