I'm still trying to figure out what the point of the shootout really is. If there's no dedicated folks working with a language there, trying to make things run faster, a language will come out looking inefficient potentially. There's a lot of compile flags and optimizations that can make a difference in probably all of the languages listed on that page. I guess all you can get from the shootout is a sense of what a particular language or set of tools is capable of in the hands of the programmers who submit implementations. It doesn't really give you a concrete idea as to how to evaluate a programming language. It does still seem kind of fun for some reason though :-) Dave On Mon, May 31, 2010 at 5:47 PM, Louis Wasserman wrote:

Hey,

I was looking at the reverse-complement benchmark on the Language Shootout, and among other things, I noticed that the Haskell implementation was using (filter (/= '\n')) on ByteStrings, and also using lists as queues.

I had a few improvements which using -fasm seem to yield about a 19% improvement in speed, and a 35% reduction in allocation, on my computer. (If both programs are compiled with -fllvm -- I'm not sure whether or not that's fair game on the Shootout -- my implementation is 35% faster, and does 10% less allocation.) I've checked my code on the Shootout's test input, as well.

Mostly, the improvement comes from a tightly specialized version of (filter (/= '\n')), although eliminating an intermediate list entirely (and one used in a queuelike fashion) didn't seem to hurt. I managed to cut the program to a point where the program size is about the same as before.

The code is at http://hpaste.org/fastcgi/hpaste.fcgi/view?id=25865; the previous implementation is at http://shootout.alioth.debian.org/u32/program.php?test=revcomp&lang=ghc&id=2 .

Let the arguing begin?

Louis Wasserman wasserman.louis@gmail.com http://profiles.google.com/wasserman.louis

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Inspired by this post I looked at the language shootout. There is one thing which strikes me: On http://shootout.alioth.debian.org/u64/performance.php?test=spectralnorm#abou... It sais for the spectralnorm benchmark that both Haskel GHC #4 and HaskellGHC produce "bad output". For GHC I connt see what's wrong because 1.274224153 seems to be the correct result. But there really seems to be something wrong with GHC#4. -- Martin