GHC FFI stub files

2010-02-21 Thread Tyson Whitehead
I'm writing a perl module that interfaces some haskell code and its a bit of a pain because both perl and ghc have their own custom build system. Is there a way to get ghc to give you the gcc/as/ld options (library paths, include paths, flags, etc) required for the FFI stub files it generates?

Some great results on fused code with the LLVM backend

2010-02-21 Thread Don Stewart
I tried out some of the vector and uvector fusion benchmarks with the new LLVM backend http://donsbot.wordpress.com/2010/02/21/smoking-fast-haskell-code-using-ghcs-new-llvm-codegen/ and got some great results for the tight loops generated through fusion. Up to 2x faster than gcc -O3 in some

Re: integer-simple by default

2010-02-21 Thread Isaac Dupree
On 02/21/10 14:18, Daniel Fischer wrote: Am Sonntag 21 Februar 2010 19:56:54 schrieb Isaac Dupree: We could try to find out how large Integers get, in practice, in existing Haskell code (this may be difficult to find out). I suspect (just guessing...) that a more reliable way to find out is to

Re: integer-simple by default

2010-02-21 Thread Daniel Fischer
Am Sonntag 21 Februar 2010 19:56:54 schrieb Isaac Dupree: > We could try to find out how large Integers get, in practice, in > existing Haskell code (this may be difficult to find out). Just as a data-point, my code rarely exceeds 128 bits (at least, beyond that performance isn't so important any

Re: integer-simple by default

2010-02-21 Thread Isaac Dupree
On 02/21/10 13:14, Ian Lynagh wrote: On Sat, Feb 20, 2010 at 02:56:53PM -0500, Isaac Dupree wrote: -what am I trying to accomplish (at least, performance-wise)? I think opinions are divided on this. Performance with word-sized Integer's is definitely important. This is true. We could start

Re: integer-simple by default

2010-02-21 Thread Ian Lynagh
On Sat, Feb 20, 2010 at 02:56:53PM -0500, Isaac Dupree wrote: > On 02/20/10 14:37, Ian Lynagh wrote: >> There's also HIntegerByInt: >> http://www.haskell.org/pipermail/libraries/2007-August/007909.html >> although it would need to be changed to user lower level types etc. > > that's true, (I w