Re: Re[4]: [Haskell-cafe] In-place modification

On 15/07/07, Hugh Perkins wrote:

On 7/15/07, Sebastian Sylvan wrote: [Lots of stuff]

Ok, Sebastian, there's such a thing as analysing products along multiple orthogonal axes.

And yet you don't seem willing to do so? Why is that? You asked for problems where Haskell does well, performance-wise, and then you make up ridiculous excuses to avoid accepting the problems presented!

So... benchmarking comes into play to find out how fast a pure computational function actually runs (point 2), and how well opengl runs (point 3.4). I didnt try opengl yet, I'm not holding my breath, but I'll give it a shot and see what happens.

OpenGL is mostly written in C, so most of the code will likely run the exact same bits. It's just an interface to a C library.

For the pure computation, FWIW my personal conclusions at the moment: - Haskell can get up to C# speeds, by using imperative algorithms - what does this say about lazy algorithms???

It says that lazy algorithms are often slower than low-level imperative algorithms. This is true in both Haskell and C#, as shown. But what do we also know about lazy algorithms? That they are far more modular and flexible! An interesting point is that lazy algorithms were (in this benchmark) two orders of magnitude faster in Haskell than in C#! So maybe if you want to focus on high-level, maintainable, and /correct/ code, you can do so at far less performance cost using Haskell?

- intuitively written, maintainable Haskell algorithms run at far from C# speeds

Actually no, it was about 100x faster! Again, you make the error of comparing a lazy stream based version with an imperative low-level version. If you want to make claims, then use either of the two apples-to-apples comparisons that we've done here. Either compare the high-level lazy versions, or the low-level imperative versions. You're comparing a low-level inflexible highly specialized algorithm to a completely different high-level and flexible (and a bit naive!) algorithm. That's not a fair comparison. It may be that Haskell is very good at writing this flexible and high level code, but that doesn't mean you get to compare it to inflexible and low level code and then claim Haskell is slow! C# was faster originally because you had to do far more work to to implement the algorithm, and the end result is hardly reusable at all, and in larger application the cost of debugging and maintenance also goes way up. But guess what? As shown in this thread, you can pay this cost in Haskell too /where needed/ and get similar speeds as C#! -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862