Profiling Garbage Collection in Haskell with DTrace & Instruments
- time slices of the mutator,
- time slices spent on garbage collection,
- the running sum of the mutator time slices,
- the running sum of garbage collection time slices, and
- the running percentage of the runtime spent on garbage collection.
Using DTrace to track scheduler events of GHC’s runtime
I finally got around to committing my instrumentation of the GHC runtime system with DTrace probes (commit message). The current set of probes tracks all the events of the eventlog framework used by ThreadScope. A detailed description of the probes is on the new Using DTrace with GHC page of the GHC developer wiki.
Four years ago the Haskell’ Committee was assembled, charged with the task to produce a new revision of the Haskell language standard (aka Haskell 98). There was a lot of enthusiasm and many wild ideas in the beginning, but it turned out that it was hard to agree on the scope of changes and that it was very hard to find a person willing to shoulder the rather large editorial burden that a major revision of Haskell entails.
The Committee finally decided that our only realistic chance of making progress was to break the mammoth task into smaller chunks. More concretely, we decided to evolve the language in small increments with a release every year, while rotating the committee on an annual basis to avoid burn out. Whether this fine-grained evolutionary approach to language design will be successful in the long run remains to be seen. Nevertheless, the new approach helped us to make progress and to agree on a revision for this year: behold Haskell 2010!
 Details about The Haskell Prime Process
Status Update of the Glasgow Haskell Compiler, October 2009
If you are interested in Haskell generally or the Glasgow Haskell Compiler (GHC) in particular, you may want to have a look at the latest issue of the biannual GHC status updates. It includes a summary of our recent progress in the Data Parallel Haskell project.
Finally found the ghci bug on Snow LeopardAfter much digging through otool output and tracing Haskell code with dtrace, log messages, and gdb, I finally found the cause of the SIGBUS errors with ghci on Snow Leopard. At the end, only a tiny change was required: the homegrown dynamic linker of ghci had simply ignored a relocation type that ld on Snow Leopard chose to use. What this really shows again is that re-implementing parts of basic infrastructure in an ad hoc manner always comes back to bite you. Such infrastructure is usually full of low-level, platform-dependent details, which you are bound to get wrong once in a while and then it can be rather involved to find the problem. In this case, the relocation of the memory access of a bit of C code in GMP, reading a global variable, went wrong. As a result, the wrong memory location was accessed, which happened to contain a NULL pointer. Upon dereferencing the NULL, the program crashed. All of this was further obscured by the fact that the homegrown linker approach of ghci implies that we have two copies of the basic libraries in memory and in use at the same time. One copy has been statically linked with the ghc executable and the second copy is dynamically loaded by ghci. The relocation in the statically linked copy was perfectly fine, but the relocation in the dynamically loaded one was broken.  http://www.haskell.org/pipermail/cvs-ghc/2009-October/050863.html
Data-oriented programming and the vectorisation transformation
I just realised that the data layout and the resulting code organisation in data-oriented programming, as proposed for games design, in many aspects resembles the data layout and code organisation favoured by the vectorisation transformation that is at the core of Data Parallel Haskell. This should not be surprising as both have similar goals, namely to maximise data throughput, to minimise stalls by utilising the memory hierarchy, and to maximise parallelism.
However, the parallels are interesting given the very different origins of both approaches. The big difference is of course that data-oriented programming is a design methodology for programmers, whereas the vectorisation transformation is a program transformation automatically applied by a compiler. Nevertheless, we may regard the vectorisation transformation as a program transformation that turns purely functional code into code that is structured in a data-oriented manner, where the layout of bulk data shapes the organisation of the code.
This raises the question of how useful nested data parallel programming and the vectorisation transformation may be to games programming.
Fun with higher-order functions in C and Objective-CThe latest release of Mac OS X (Snow Leopard) came with an upgrade to the C and Objective-C languages, adding lambda abstractions — which they call blocks. Matt Gallagher has a nice blog post that describes some of the trickier aspects of blocks: http://cocoawithlove.com/2009/10/ugly-side-of-blocks-explicit.html Interesting is the function ‘newDoubleToIntComparison’ (in Section “Declaring a block that returns a block”), which is a curried version of ‘compareDoubleToInt’. Together with the explicit memory management for returned blocks and the need for involved type annotations and casts, it becomes clear why functional languages like Haskell make curried functions the default as well as support garbage collection and type inference out of the box.  http://en.wikipedia.org/wiki/Currying
Multicore Haskell Now!
Don Stewart summarised the state of play of parallel programming in Haskell at “ACM Reflections | Projections 2009”. He covers strategies, Concurrent Haskell, STM, and Data Parallel Haskell: http://donsbot.wordpress.com/2009/10/17/multicore-haskell-now-acm-reflections-projections-2009/
Don Stewart’s talk on Domain Specific Languages and Haskell
Don argues in favour of domain-specific languages for high-performance computing. Not surprisingly, he suggests that Haskell is well suited as a host for realising such domain-specific languages as embedded languages: http://donsbot.wordpress.com/2009/10/16/lacss-2009-domain-specific-languages-and-haskell/