On 15/07/07, Hugh Perkins
Sebastian,
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. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862