Final issues to fix for the shootout entries (Was: no subject)

Yeah, have a look on the shootout: http://shootout.alioth.debian.org/gp4/benchmark.php?test=recursive&lang=all Has an ackerman. More detailed comparisions, across the 19 benchmarks on the shootout, with notes on which of the 19 GHC Haskell is significantly slower (>4x) at: Haskell verus Python http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=ghc&lang2=python Loses on: regex-dna Haskell verus Ruby http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=ghc&lang2=ruby Loses on: regex-dna Haskell verus Perl http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=ghc&lang2=perl Loses on: regex-dna Haskell verus Lisp http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=ghc&lang2=sbcl Loses on: mandelbrot (Double math) spectral-norm (Double math) Haskell verus Clean http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=ghc&lang2=clean Loses on: k-nucleotide ( HashTable benchmark) mandelbrot spectral-norm Haskell verus SML http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=ghc&lang2=mlton Loses on: k-nucleotide mandelbrot spectral-norm Haskell versus OCaml http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=ghc&lang2=ocaml Loses on: k-nucleotide mandelbrot regex-dna spectral-norm Haskell versus C Loses on: k-nucleotide mandelbrot regex-dna spectral-norm Fixing these last few programs: k-nucleotide: Needs a better hashtable library implementation. For example a Data.HashByteString based on a Trie of ByteString) regex-dna: Should use the regex-tre library instead of regex-posix (algorithm issue only) mandelbort/spectral-norm: Double math is slow. I don't know why. And note that strings aren't a bottleneck anymore! http://shootout.alioth.debian.org/gp4/benchmark.php?test=sumcol&lang=all -- Don seth:
GHC has profiling support.
(By the way, many mail servers these days discard mail with no subject.)
I've seen a number of papers comparing the speed of Haskell code to code of other functional languages; there is a periodic "shoot out" with ocaml.
Some probably have comparisons with imperative languages, and, even if they do not, the methodology should help you.
Seth Kurtzberg
On Mon, 5 Feb 2007 11:28:03 -0800 (PST) Tays Soares
wrote: Hello everyone,
I did at my master thesis a compiler that generates Haskell code. Now I need to measure the execution time of my generated code and I've been searched and I don't know if I'm looking with the wrong keywords but I could not find anything. I just need to measure the time of simple functions, like Ackermann and Fibonacci. Does anyone know how to measure the execution time of a Haskell program or function?
Thank you, Tays
__________________________________________________ Fale com seus amigos de gra?a com o novo Yahoo! Messenger http://br.messenger.yahoo.com/
Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

On Tue, Feb 06, 2007 at 12:12:09PM +1100, Donald Bruce Stewart wrote:
And note that strings aren't a bottleneck anymore!
http://shootout.alioth.debian.org/gp4/benchmark.php?test=sumcol&lang=all
I think "Haskell GHC #2" doesn't play by the rules: " diff program output for this 6KB input file with this output file to check your program is correct before contributing. Each program should be implemented the same way as this Icon program. The sum-file benchmark measures line-oriented I/O and string conversion. Each program should: * read integers from stdin, one line at a time * print the sum of those integers Programs should use built-in line-oriented I/O functions rather than ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ custom-code. No line will exceed 128 characters, including newline. ^^^^^^^^^^^^ Reading one line at a time, the programs should run in constant space. " Best regards Tomasz
participants (2)
-
dons@cse.unsw.edu.au
-
Tomasz Zielonka