Hello Sebastian, Monday, July 16, 2007, 2:53:36 PM, you wrote:
But wouldn't you say that in general, if you spend the effort you can write low-level imperative algorithms in Haskell that perform reasonably well? Especially compared to e.g. C#? I think your own libraries demonstrate this!
i've said that 1) low-level programming in Haskell is possible, although not as convenient as in C 2) low-level code will be much faster than high-level one, but not as fast as C code once i summed up my experience - you may either write 1) high-level code, which is written 10x faster than in C but works 100x slower 2) low-level code that is written 3x slower than in C and works 3x slower too if you think that Haskell code may be as fast as C one - try to rewrite sha1 in any haskell style and compare it to highly optimized C versions it's all about small self-contained "number-crunching" algorithms - for larger ones and especially for whole applications i got very different results - code is, say, 3x slower while written 3x faster. it's probably because OS calls, C libraries and highly-optimized libraries written by other people are taken into account; also ghc imho has better global-level optimization than C++ compilers, for example it has better inlining policy
I'm not saying it's as convenient (see the recent thread about "monad splices") to write low-level imperative code in Haskell, but using laziness in C# was hardly a walk on the beach either! So my point is that Haskell isn't geared towards low-level optimizations and performance, but in the few places where you do need it, you *can* get it (IMO for only moderately more inconvenience than you pay for *everything* in a low-level imperative language).
are you really wrote such code or just believe to Haskell advertizing company? :D -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com