On Sun, May 23, 2010 at 5:47 PM, Henning Thielemann <lemm...@henning-thielemann.de> wrote: > > On Sun, 23 May 2010, Sönke Hahn wrote: > >> On Friday, May 21, 2010 11:45:18 am John Lato wrote: >>> >>> You could try compiling the time-critical stuff with ghc -O2, then >>> just load the object files with ghci. That might give better results. >> >> IIRC, you can configure ghci not to run the code interpreted but to >> compile it >> first. > > This is certainly equivalent to the -fobject-code option and means that > modules are compiled (and optimized) when loaded.
I thought that might be the case, but I didn't know if ghci would perform all the optimizations that ghc would. > As far as I know, > expressions you type into GHCi are not compiled (and thus not optimized). > Then expressions like > mix signalA signalB > can be fast, if 'mix' is monomorphic (I'm afraid a 'SPECIALISE mix' is not > enough), but slightly more complicated examples like > oscillator wave freq > where 'wave' is a function, are slow, since the 'oscillator' and 'wave' > must be inlined for efficient execution. > > 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. Best, John _______________________________________________ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
