I&#39;m still trying to figure out what the point of the shootout really is.  If there&#39;s no dedicated folks working with a language there, trying to make things run faster, a language will come out looking inefficient potentially.  There&#39;s a lot of compile flags and optimizations that can make a difference in probably all of the languages listed on that page.<div>
<br></div><div>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&#39;t really give you a concrete idea as to how to evaluate a programming language.</div>
<div><br></div><div>It does still seem kind of fun for some reason though :-)</div><div><br></div><div>Dave<br><br><div class="gmail_quote">On Mon, May 31, 2010 at 5:47 PM, Louis Wasserman <span dir="ltr">&lt;<a href="mailto:wasserman.louis@gmail.com">wasserman.louis@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hey,<div><br></div><div>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 (/= &#39;\n&#39;)) on ByteStrings, and also using lists as queues.  </div>


<div><br></div><div>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&#39;m not sure whether or not that&#39;s fair game on the Shootout -- my implementation is 35% faster, and does 10% less allocation.)  I&#39;ve checked my code on the Shootout&#39;s test input, as well.</div>


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


<div><br></div><div>The code is at <a href="http://hpaste.org/fastcgi/hpaste.fcgi/view?id=25865" target="_blank">http://hpaste.org/fastcgi/hpaste.fcgi/view?id=25865</a>; the previous implementation is at <a href="http://shootout.alioth.debian.org/u32/program.php?test=revcomp&amp;lang=ghc&amp;id=2" target="_blank">http://shootout.alioth.debian.org/u32/program.php?test=revcomp&amp;lang=ghc&amp;id=2</a>.</div>


<div><br></div><div>Let the arguing begin?</div><div><br clear="all">Louis Wasserman<br><a href="mailto:wasserman.louis@gmail.com" target="_blank">wasserman.louis@gmail.com</a><br>

<a href="http://profiles.google.com/wasserman.louis" target="_blank">http://profiles.google.com/wasserman.louis</a><br>
</div>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br></div>