[Haskell-cafe] In-place modification
Bulat Ziganshin
bulat.ziganshin at gmail.com
Mon Jul 16 08:09:40 EDT 2007
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 at gmail.com
More information about the Haskell-Cafe
mailing list