Re: [Haskell-cafe] Language Shootout reverse-complement benchmark
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#about 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Language Shootout reverse-complement benchmark
On a similar note, there was no parallelized implementation for spectral-norm, even though Haskell had been doing rather well on the single-core benchmark. Heh. Louis Wasserman wasserman.lo...@gmail.com http://profiles.google.com/wasserman.louis On Tue, Jun 1, 2010 at 10:38 AM, Gwern Branwen gwe...@gmail.com wrote: On Tue, Jun 1, 2010 at 10:25 AM, David Leimbach leim...@gmail.com wrote: 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. 'Out of the crooked timber of humanity, no straight thing was ever made.' 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 The Shootout has a number of valuable purposes: 1) Concrete evidence that language X *can*, somehow, be as fast as language Y 2) Public examples of techniques to do #1, again concrete 3) Exposes where libraries/compilers can do better (this has happened many times with GHC and Haskell libraries) 4) Motivates people to work on creating/fixing #2 and #3 -- gwern ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Language Shootout reverse-complement benchmark
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=revcomplang=ghcid=2 . Let the arguing begin? Louis Wasserman wasserman.lo...@gmail.com http://profiles.google.com/wasserman.louis ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Language Shootout reverse-complement benchmark
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 wasserman.lo...@gmail.comwrote: 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=revcomplang=ghcid=2 . Let the arguing begin? Louis Wasserman wasserman.lo...@gmail.com http://profiles.google.com/wasserman.louis ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Language Shootout reverse-complement benchmark
On Tue, Jun 1, 2010 at 10:25 AM, David Leimbach leim...@gmail.com wrote: 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. 'Out of the crooked timber of humanity, no straight thing was ever made.' 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 The Shootout has a number of valuable purposes: 1) Concrete evidence that language X *can*, somehow, be as fast as language Y 2) Public examples of techniques to do #1, again concrete 3) Exposes where libraries/compilers can do better (this has happened many times with GHC and Haskell libraries) 4) Motivates people to work on creating/fixing #2 and #3 -- gwern ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
