[Haskell-cafe] In-place modification

[Sebastian Sylvan]

On 15/07/07, Hugh Perkins <hughperkins at gmail.com> wrote:
> On 7/15/07, Sebastian Sylvan <sebastian.sylvan at gmail.com> 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