[Haskell-cafe] In-place modification
sebastian.sylvan at gmail.com
Sun Jul 15 06:22:11 EDT 2007
On 15/07/07, Hugh Perkins <hughperkins at gmail.com> wrote:
> Why would I write a slow, complicated algorithm in C#?
> I'm not making these comparisons for some academic paper, I'm trying to get
> a feel for how the languages run in practice.
> And really in practice, I'm never going to write a prime algorithm using
> merge and so on, I'd just use the original naive Haskell algorithm, that
> runs 500 times slower (at least) than my naive C# algo. I'm just allowing
> you guys to optimize to see how close you can get.
> Note that the C# algo is not something created by C# experts, it's just
> something I hacked together in like 2 minutes.
I take it you really are using the Sieve as a final program then? And
not just as a benchmark?
Because if you *are* trying to compare the two languages fairly, then
your reply just doesn't make sense. Just because you aren't using the
laziness of your data structure in the Haskell version for this
benchmark doesn't mean it's not there, and could be exploited in a
*real* program. Therefore if you want to compare it to C# you can't
just ignore the main properties of the Haskell version in order to
make it faster in C#! Heck, take that to its extreme (you don't seem
to care much about using the same algorithm in both languages anyway)
you could just hard code the answer for all 32 bit numbers in a large
table for the C# version and claim it's millions of times faster!
The C# algorithm is the same as the Haskell algorithm! You can't just
pick and choose two different algorithms and say that one of the
languages is better based on that!
It's like saying C is faster than Erlang on your computer, even though
Erlang scales to hundreds of threads ("Why would I write something
using threads in C?"). Stick with one algorithm, and implement it in
the same way in both languages, and then compare. If one of the
languages manages to handles this more gracefully and elegantly,
that's beside the point and doesn't give you the license to go off and
do something completely different in the other language and still
think you have anything useful on your hands.
The fact is that languages are different, with different strenghts and
weaknesses. Whatever comparison you come up with, chances are that one
of the languages will deal with it more gracefully. If you implement
something using lazy streams, Haskell will be more elegant, if you
want to use low level pointer arithmetic than C will do better etc. So
either you have to implement a Haskell version of your C# code, or
implement a C# version of your Haskell code (which I did). Just
because the benchmark is simple, doesn't mean you can tailor-fit the
algorithm to the specific properties of the benchmark in one of the
instances, while keeping it general and nice in the other.
More information about the Haskell-Cafe