I have made the slides (in Dutch) available in PDF format. Ignore the jokes if you do not grok them.

Thanks Zeus, for the Grimbergen bottles. I will make them count.

Basically, I used Snap to deal with requests, routing them to a handler that uses two Snap extensions: the HDBC extension and a filesystem cache extension I wrote. When a sequence is submitted to hCole-server in the form of a string consisting of ints separated by dashes, there are four possible outcomes:

1. This a new sequence that has never been requested before.
2. The sequence has been requested in the past, but the experiment is still running.
3. The results for the sequence are available in the filesystem cache.
4. Some error occurred.

In the first case, a new job is prepared and started, the database is updated to reflect this (inserting a busy entry for this sequence) and the server waits for the next request. In the second case, we return a JSON string indicating we’re still waiting for results to roll in. In the third case, we extract the measurements from the tarball and wrap it in a JSON data structure and return it as the server response. In the last case, we oops. This is also illustrated in the following figure.

Because the experiment scripts automagically fetch completed jobs from the supercomputer and store them as tarballs in the file system cache, we need a way to update the database when a new tarball rolls in. For this, we spawn a second thread that periodically checks the file system for new files that correspond to a busy entry in the database. When a corresponding tarball is found, the thread updates the databse, changing the state for the sequence from busy to done.

You can find the slides of the talk (mostly code) here.

Note that all code was written for Snap 0.5.x and may fail for newer versions of the framework.

The real issue is that the statistics are based on trains, not people. No matter the number of people who will incur a real delay due to their train not being on time in some station — either an endpoint of a transit station — the NMBS will only count a single instance. To them, a train that has a delay at, say 2 p.m., is weighted equally with a delayed rush hour train. Obviously, the latter situation impacts a lot more travelers: people not making it to a connection train, tram or bus, or simply getting home later. The problem with connecting trains is that this may increase the real delay up to one hour or more. And it happens at minimum once every week.

I agree that the NMBS cannot fix all problems, and in some cases, they have no say in the matter, since the (old) NMBS has been split into three parts: the (new) NMBS, the infrastructure controller (Infrabel) and the holding linking the two. When a train breaks down, or an accident occurs, it is Infrabel that decides where and when the other trains will be (re)routed. Yet they have no passenger information (neither does the NMBS for that matter).

The real goal when solving a problem could take some lessons from computer science. Let us consider the trains to be processes that somehow have some dependencies between them. When one process breaks down or stops, because it has to wait for some data to become available, the other processes may be impacted since they may need access to some shared resource that is now being occupied by the stalled process (the borked train in our analogy). The operating system can then decide to force the offending process to release the resource (for a while) such that other processes can continue executing. Now, the analogy is not completely right, but you catch my drift, I’m sure. How would the OS decide which process can then take a hold of this shared resource? One way is to assign priorities to each process and have the process with the highest priority continue first. In the real world of trains there is a small (actually, a large) catch. Trains cannot overtake each other, except at certain well defined places (e.g., a station).

But let us first start with the priorities. How could we assign those to a train. Actually, there seems to be, IMHO, a quite simple solution for this. Every passenger needs to have a valid ticket before getting on the train. How about we change our infrastructure (that would yield jobs!) and force people to validate their ticket before getting on the platform. Moreover, you could deny access if their train is not coming within the next 15 minutes or so, or if there’s a previous train they cannot take (wrong ticket) still waiting. Since each ticket is used between two endpoint — and only very occasionally between the starting point and a station before the real end point — this yield information on how many people are traveling at each moment between any two train stations. Furthermore, since people tend to take the (theoretically) fastest route, it is quite predictable which station will be used for connecting trains (if people need to descend from the platform and revalidate their ticket, even this poses no issue). Thus, the NMBS (and by extension, Infrabel) have data on the number of passengers on each train and on how many people will miss their connecting train if they incur a delay. Hence, when a problem occurs (not an uncommon event on the Belgian railways), Infrabel can decide which trains to let pass first and which ones to (temporarily) put on a side track, such that the least number of people will be impacted and their overall/maximum delay will be as small as possible.

A boon of this system is that the NMBS will have objective numbers to decide how to schedule trains. Right now, they have some vague idea (commuters are known beforehand, but not the time at which they commute) and other travelers are mostly known on the moment they purchase a ticket. But once people are (anonymously) scanned, they gain knowledge. Patterns may arise (summer holiday travelers going to the coast, etc.) and trains can be scheduled much more effectively.

The above might not impact the number of trains incurring a delay, but it should certainly impact the number of affected travelers. While the former do not complain, the latter do. Quite loudly at times, and righteously so.

Ranking Commercial Machines through Data Transposition, Beau Piccart, Andy Georges, Hendrik Blockeel, Lieven Eeckhout.

The abstract of the paper reads as follows.

The performance numbers reported by benchmarking consortia and corporations provide little or no insight into the performance of applications of interest that are not part of the benchmark suite. This paper describes data transposition, a novel methodology for addressing this ubiquitous benchmarking problem. Data transposition predicts the performance for an application of interest on a target machine based on its performance similarities with the industry-standard benchmarks on a limited number of predictive machines. The key idea of data transposition is to exploit machine similarity rather than workload similarity as done in prior work, i.e., data transposition identifies a predictive machine that is most similar to the target machine of interest for predicting performance for the application of interest.

We demonstrate the accuracy and effectiveness of data transposition using the SPEC CPU2006 benchmarks and a set of 117 commercial machines. We report that the machine ranking obtained through data transposition correlates well with the machine ranking obtained using measured performance numbers (average correlation coefficient of 0.93). Not only does data transposition improve average correlation, we also demonstrate that data transposition is more robust towards outlier benchmarks, i.e., the worst-case correlation coefficient improves from 0.59 by prior art to 0.71. More concretely, using data transposition to predict the top-1 machine for an application of interest leads to the best performing machine for most workloads (average deficiency of 1.2\% and max deficiency of 24.8\% for one benchmark), whereas prior work leads to deficiencies over 100\% for some workloads.

You can get a preprint of the paper (subject to change for the final submitted version).

September 1st is once more a dreaded date. Not that I do not like to go back to work, but because I really enjoyed heaps of quality time with my family. Still, traditions must be honoured, so I’ll start work with two days of leave. Thus, I still have two weeks of vacation. Except that I already seem to be doing some work in the evening

We stayed at the Cambridge YHA, in a room we shared with Simon Meijer and some unnamed Belgian guy from Moeskroen, whose Dutch resembled West-Flemish quite closely. The latter was there to study during the day and party during the night. And he was not happy with the fact that we got up around 8:00 AM I only discovered a shower with warm water on Sunday, having taken cold shower — I mean really cold — the previous two days. But the breakfast more than made up for that.

When signing up to CamHac, I had the plan to work on HaBench, or rather, see how Fibon could be made into what we envisioned during BelHac as a Haskell benchmark suite. However, research requirements dictated otherwise. Given that we are collaborating with researchers from the KULeuven on a project using COLE and active learning to build models for the effect of optimisation sequences, and that the COLE framework requires access to the supercomputer backend at Ghent University, I decided to write a Haskell web application using Snap that would allow the submission of optimisation sequences and get the results for the objective functions (speedup, compilation time, code size, …) back for the used benchmark suite. Having no previous experience with Snap, I found the framework to be easy to use. The core of the application was finished by Sunday afternoon; on the way home I added a watchdog thread to update the database with finished experiments.

I had a ton of fun those three days, learned a lot, and — fingers crossed — started to grok monads a bit better. The event was full, as 72 people registered. I am not sure everybody turned up, but the room was crowded at all times. And a lot of work was done, see the post-hackathon report.

Predictive Learning in Two-way Datasets, by Beau Piccart, Hendrik Blockheel, Andy Georges and Lieven Eechout.

The abstract of the paper reads as follows:

We introduce a new learning setting, called two-way predictive learning, as a special case of relational learning. We demonstrate that this learning setting has some properties that make an alternative learning approach, which we refer to as transposed learning, possible. We show experimentally that transposed learning can yield better results in multi-target learning settings.

We have used this approach to improve on the results we obtained in out PACT 2006 paper, titled “Performance Prediction based on Inherent Program Similarity”. The full results of that research will be part of a future paper.

Next to that, I also gave a (short) talk on the metrics we devised for quantifying (throughput) performance in a consolidated system. That talk was pretty much the same I gave at HPCVirt earlier this year, so no new slides for that, excepting a few changes. In the meantime, SPEC has published SPECvirt, and they at least seem to be being this a bit better than VMmark, but we still have to wait for more published results to become available before unleashing our wrath on it, should they do things in the wrong way

During this trip, I met a bunch of cool, hospitable people who are busy doing some pretty interesting research. I must confess that I had even worse issues than normal remembering names. Czech clearly is not my forte After the exchange of ideas and thoughts, the trip definitely seemed to have been worthwhile.

The flight to Prague was pretty uneventful, but the return flight was delayed somewhat thanks to the small snow storm that decided to pick its timing in the worst possible manner to pass by and say hello. Our airplane first taxied to one runway, was de-iced there and then had to taxi all the way back to the start of the other runway, as the one we had previously been assigned to for takeoff had been snowed under too much, I think. BTW, Czech Airlines. Free food and a free drink plus coffee or tea. Eat that, Brussels Airlines. After the landing, we were not allowed to taxi up to the gate immediately for undisclosed reasons, but it made me have to run to catch a train. I skipped the purchase of the obligatory Diabolo ticket and filled in the Rail Pass with unauthorised writing gear (a ballpoint pen is obligatory, but I had only a regular pen with me). Luckily — unexpectedly too — the train arrived on time at Brussel-Noord and I could still purchase the Diabolo tax ticket. Thanks to the new schedule — which will prove to be bad in the coming days, I’m sure — I made it to the IC train to Ostend. The NMBS even managed to deliver me on time at my final destination. A rare feat, I agree.

Thanks to Ghent University, we had obtained a nice venue: a refurbished coal power plant, of which we could use the upper floor, where the huge silos for storing the coals were located.

The event entailed three days. On Friday we had the registration, the hey-cool-to-see-you-are-here-too and general get-to-know each other, followed by a very nice talk by Miran Lipovača, the author of the ‘Learn you a Haskell for great good’ book (soon to be available from your favorite bookshop(s)). From 5 p.m. onwards, we had the Functional Programming in Industry symposium, where Duncan Coutts, Romain and Donald Steward entertained the masses with great stories about using FP in their daily work. Since we be engineers, and the tradition of our department states that talks in the Jozef Plateau-room are followed by a reception (at least, when people defend their PhD. this is the case, but let’s ignore that little trivia for the moment), we also fed the masses with a bunch of excellent (220) sandwiches. Sadly, some were left over, even though the local folks ate more than (twice) their share once it became clear that there would be leftovers. No worries, we’re well trained, given the number of PhD’s defended every year.

The weekend itself was pretty much devoted to the actual hacking. Kenneth (boegel) and I found some support for our HaBench effort in the person of Yuriy Kashnikov. After a round of project introductions, the work began in earnest only to be briefly interrupted by the announcement that food was available, kindly provided by Het Stokbroodje (we paid, of course, but still, the food was yummy and they delivered on both Saturday and Sunday). The evening saw a march with a few hackers to Julien, Ghent’s moat famous french fries place (I’m told).

On Sunday, hacking continued and in the afternoon, a few 5-minute lightning talks were held by people who considered having made significant progress. I briefly talked about HaBench (slides (PDF)). The general reception was pretty good, I believe. Clearly, a new benchmark suite is highly desirable. Finally, we wrapped up and cleaned shop before the housekeeper came round to chase us out again.


type MollomState = ReaderT MollomConfiguration (StateT MollomServerList IO)
type MollomMonad = ErrorT MollomError (StateT (Maybe SessionID) MollomState)


The main concept of the code remains the same, each exported function calls the service function. The latter returns a MollomState a, to capture the fact that during the Mollom request, we potentially need to update the list of servers we can query with API calls. This result is then lifted into the MollomMonad stack by using the following function.


returnStateT a = StateT $ \s -> liftM (flip (,) s) a


This is illustrated in the following control flow figure (for a full sized image, follow the link to flickr):

The error handling is done by usage of the ErrorT monad transformer, which add the possibility to return a Left MollomError as function value, indicating a fault during the handling of the request. At this point, I have not added a decent runMollomMonad function, as I am still pondering which functions may be most useful for the users of this library. However, you can easily employ the following function, where defaultMollomConfiguration :: MollomConfiguration and we start without any servers that are available.


(\m -> (runStateT $ (runReaderT $ (runStateT . runErrorT $ m) (Nothing) ) defaultMollomConfig) UninitialisedServerList)


As usual, the code is available from both the GitHub repository, as well as from Hackage. All feedback is welcome. Thanks to #haskell and #ghentfpg for bearing with my questions.