Re: integer-simple by default
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 a discussion on the Libraries list -- although I'm sure it would also not reach a clear conclusion. We could try to find out how large Integers get, in practice, in existing Haskell code (this may be difficult to find out). We could make sure there's a good non-builtin-to-ghc GMP-binding library (Is there one? Is it even possible yet, in a way that doesn't conflict with GHC's builtin GMP?). Then people would have a place to turn if they need GMP's performance for something particular. -what might be a good low-level format? (And is it important to strew unboxed ints all over the place, or is it fine to skip this and count on the optimizer?) I think relying on the optimiser is OK, but don't forget that you don't have the standard (+) etc. oh okay, interesting. I think I'd best start by finding out where integer-simple lies in the dependency tree. -Isaac ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: integer-simple by default
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 anymore). ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: integer-simple by default
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 instrument integer-simple to report the sizes of integers it handles. For example, if you use Rational, (even toRational/fromRational), you might be handling Integers somewhat larger than you thought you were. And this could also report on how often the integers get that large. (Also it's probably only tough operations like multiplication and division that we need to worry about for large numbers. It's easy to get linear-time addition, etc. Incidentally, for operations like Large Number plus or minus Small Number, it's possible to use a representation that has laziness and sharing to achieve amortized O(min(m,n)) time. Which is a nice property... which I believe I implemented in HIntegerByInt... but there are probably disadvantages to doing it this way too.) -Isaac ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Some great results on fused code with the LLVM backend
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 cases. The LLVM backend looks very promising -- considering we've not even begun to explore the optimization pipeline at the level. -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC FFI stub files
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? The best I've come up with so far is to extract them from GHC by telling it to use a capture the arguments command as the compiler and linker. Thanks! -Tyson (I could also tell the perl build system that ghc is c compiler, assembler, and linker, but then I need to do a bunch of wrapping with -optc and friends) signature.asc Description: This is a digitally signed message part. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
