On Mon, May 24, 2010 at 9:56 AM, Henning Thielemann <[email protected]> wrote: > > On Mon, 24 May 2010, John Lato wrote: > >> On Sun, May 23, 2010 at 5:47 PM, Henning Thielemann >> >>> With the LLVM based signal processing EDSL that I developed recently >>> (http://arxiv.org/abs/1004.4796) you could in principle generate fast >>> signal >>> processing code from GHCi. However sadly, in LLVM-2.6 GHCi aborts with a >>> failed LLVM assertion, whereas LLVM-2.5 could be pursuaded to work with >>> GHCi >>> with a bit of effort. >> >> Thanks for sharing that paper; I look forward to reading it! I've >> done some experimenting with LLVM code generation recently, >> unfortunately it didn't work out quite how I would have liked (mostly >> due to OS/llvm version problems on which progress has been made). >> I've just begin experimenting with a CCA-based system instead, and it >> would be interesting to compare the two once my work is a little >> further along. In particular, I think the CCA code with ghc's LLVM >> backend could be competitive. > > Actually I use causal arrows for the LLVM code generation (additional to the > causal arrow code in > http://code.haskell.org/synthesizer/core/src-4/Synthesizer/Causal/Process.hs). > However it will certainly need some more time until GHC supports CPU vector > types, and even more time to support CPU specific vector operations. Both of > these features are already available in LLVM. For instance I have written > some ix86 specific optimizations: > http://code.haskell.org/~thielema/llvm-extra/src/LLVM/Extra/Vector.hs > http://code.haskell.org/~thielema/llvm-2.6/
I've just finished the paper, and I had thought that LLVM only supported vector operations on Apple/OS X. It seems that this is no longer true, which is great progress. I did note that you use causal arrows, however (at least from reading the paper) it seems that you aren't yet making use of the most significant contribution of the CCA framework, namely the algorithm to reduce any causal commutative arrow to a normal form of one function and an initial state. Maybe in your case the LLVM optimizer is able to perform similar transforms, but it would be interesting to see if their procedure would affect your code generation framework. It may be a bit of work to implement, unfortunately. The CCA algorithm is polymorphic over arrow types, but since your arrows are LLVM "black boxes" instead of functions I think you'd need to create proxies to represent your basic generators and processes. The CCA work is still in progress so there are some ongoing changes. Also I just noticed that their ArrowInit class specifies ArrowLoop as a superclass, when IMHO it should be the other way arround. I suspect they did this for interoperability with the existing ArrowLoop, similar to the Functor/Monad mess. Best, John _______________________________________________ haskell-art mailing list [email protected] http://lists.lurk.org/mailman/listinfo/haskell-art
