[Haskell-cafe] my Fasta is slow ;(

[Bryan O'Sullivan]

I've already submitted it, thanks.

The Fortran program commits the same sin as the C++ one, of doing floating
point arithmetic in the inner loop; that's why it's slow.

On Dec 27, 2012, at 18:05, Branimir Maksimovic <bmaxa at hotmail.com> wrote:

 Thank you. Your entry is great. Faster than fortran entry!
Dou you want to contribute at the site, or you want me to do it for you?

------------------------------
Date: Thu, 27 Dec 2012 15:58:40 -0800
Subject: Re: [Haskell-cafe] my Fasta is slow ;(
From: bos at serpentine.com
To: bmaxa at hotmail.com
CC: haskell-cafe at haskell.org

On Tue, Dec 18, 2012 at 12:42 PM, Branimir Maksimovic <bmaxa at hotmail.com>wrote:


Seems to me that culprit  is in function random as I have tested rest of
code
and didn't found speed related  problems.


The problem with your original program was that it was not pure enough.
Because you stored your PRNG state in an IORef, you forced the program to
allocate and case-inspect boxed Ints in its inner loop.

I refactored it slightly to make genRand and genRandom pure, and combined
with using the LLVM back end, this doubled the program's performance, so
that the Haskell program ran at the same speed as your C++ version.

The next bottleneck was that your program was performing floating point
arithmetic in the inner loop. I changed it to precompute a small lookup
table, followed by only using integer arithmetic in the inner loop (the
same technique used by the fastest C fasta program). This further improved
performance: the new Haskell code is 40% faster than the C++ program, and
only ~20% slower than the C program that currently tops the shootout chart.
The Haskell source is a little over half the size of the C source.

You can follow the work I did here: https://github.com/bos/shootout-fasta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20121228/c747e341/attachment.htm>