Hi
Thanks to everyone that have helped, the runtimes for the haskell
programs have decreased significantly, presently they look like this
compared to O'Caml:
Benchmark haskell ocaml
drop3 5.786 3.151
five11 8.657 7.692
huffman 7.134 18.593
uudecode6.
It seems I have spoken too soon!
> There is one infidelity in my implementation: the program writes the
> output once per iteration, and this IO is included in the measured
> time.
Due to a few changes, this caveat no longer applies. As a result
Haskell performs just a bit better. The code is st
I have rewritten the Huffman benchmark (see
http://cse.unl.edu/~sjanssen/huffman.hs), resulting in a significant
performance increase. On my computer it completes one iteration in
about 0.9 seconds. In comparison, the O'Caml version takes around 3.1
seconds. These samples seem to indicate that t
per.gustafsson:
>
> Haskell gurus,
>
> We have made a proposal to extend the Erlang `binary' data type from
> being a sequence of bytes (a byte stream) to being a sequence of bits (a
> bitstream) with the ability to do pattern matching at the bit level.
>
> Our experience in writing efficient (a
Per Gustafsson wrote:
>
> Haskell gurus,
>
I am not a guru, but I'll clean up some of this.
> Our experience in writing efficient (and beautiful) Haskell programs is
> close to (if not below) zero. Also, perhaps our mind might be suffering
> from severe case of strictness and might be completely
One thing I noticed, is that you are measuring IO in the Haskell
version of drop3. hGetContents is lazy.
On Mar 22, 2006, at 4:43 PM, Per Gustafsson wrote:
Also, perhaps our mind might be suffering
from severe case of strictness and might be completely unable to
`think
lazily'. So, we requ
Haskell gurus,
We have made a proposal to extend the Erlang `binary' data type from
being a sequence of bytes (a byte stream) to being a sequence of bits (a
bitstream) with the ability to do pattern matching at the bit level.
This proposal has now been fully implemented all
these at the level o
