text: We discuss a programming language for real-time audio signal processing that is embedded in the functional language Haskell and uses the Low-Level Virtual Machine as back-end. With that framework we can code with the comfort and type safety of Haskell while achieving maximum efficiency of fast inner loops and full vectorisation. This way Haskell becomes a valuable alternative to special purpose signal processing languages.
  @cite_21: If you want to program a parallel computer, a purely functional language like Haskell is a promising starting point. Since the language is pure, it is by-default safe for parallel evaluation, whereas imperative languages are by-default unsafe. But that doesn't make it easy! Indeed it has proved quite difficult to get robust, scalable performance increases through parallel functional programming, especially as the number of processors increases. A particularly promising and well-studied approach to employing large numbers of processors is to use data parallelism. Blelloch's pioneering work on NESL showed that it was possible to combine a rather flexible programming model (nested data parallelism) with a fast, scalable execution model (flat data parallelism). In this talk I will describe Data Parallel Haskell, which embodies nested data parallelism in a modern, general-purpose language, implemented in a state-of-the-art compiler, GHC. I will focus particularly on the vectorisation transformation, which transforms nested to flat data parallelism, and I hope to present performance numbers.
summary: Our goal is to make use of the elegance of programming for signal processing. Our work is driven by the experience that today compiled code cannot compete with traditional signal processing packages written in C. There has been a lot of progress in recent years, most notably the improved support for arrays without overhead, the elimination of temporary arrays ( fusion ) and the Data-Parallel Haskell project @cite_21 that aims at utilising multiple cores of modern processors for array oriented data processing. However there is still a considerable gap in performance between idiomatic code and idiomatic C code. A recent development is an LLVM -backend for the GHC Glasgow Haskell Compiler . that adds all of the low-level optimisations of LLVM to GHC . However we still need some tuning of the high-level optimisation and a support for processor vector types in order to catch up with our EDSL method.