Hello Ketil, Thursday, November 5, 2009, 12:00:44 PM, you wrote:
- while i say that haskell is slow compared to other languages,
The "other languages" being C and C++. I believe Haskell is fast compared to Ruby, Python or Lisp.
of course
i don't say that it is slow for you or that you need sped at all. why it's repeated again and again? why you don't write to Don what you don't need speed when he wrote that haslkell is fast
I'm not saying I don't need speed. I need programs that are fast *enough*, and I would like to build them with a minimum of effort on my part.
well, why you don't write this to Don? what i said is just what ghc generates much slower code that gcc. there is nothing in my letter about your haskell usage, so why it's all?
Which is why I would like to see how fast GHC can make more idiomatic Haskell code.
i think it would be more natural to write this to someone who thinks that haskell is fast based on measurements on non-idiomatic code rather than to me
but wrote this to me? :(
Because I am trying to agree with you. :-)
really? :/
Many of those people are making fairly simple mistakes. I think a somewhat seasoned programmer using good libraries can write declarative, concise, and readable code that still is reasonably fast.
i don't think that omitting strictness declarations is a mistake :)
If your program is slow because you misunderstand how laziness affects execution, and if it's easily fixed by adding a bit of strictness, then, yes, that is the kind of mistake I'm talking about.
for me, analyzing of slow program and finding where to add "bit of strictness" isn't something easy. it's whole optimization work and finally you got with need of strict lists or strict arrays
At least for some approximation of the word. Only one benchmark on the shootout has C at a 3x advantage.
oh, can we stop saying about shootout?
I'm using the numbers that are available, you are free to suggest better benchmarks.
it's here:
if you want to see speed of pure haskell code, look at papers about fast arrays/strings - their authors have measured that lazy lists are hundreds times slower than idiomatic C code. is use of lazy lists counted as mistake too
Yes!? You don't have to program a lot of Haskell to realize that for performance sensitive data, you need to use ByteStrings or some other packed data structure, not lazy lists of Chars. Many of those complaining on poor performance are advised to use ByteStrings instead, and more often than not, it helps tremendously.
the problems is what it's string-only and doesn't speed up even all programs using strings (for example, we have hand-made BS.readInt operation since it cannot be made efficient w/o low-level coding). another example - afaik, there is no BS version of ParseC what demonstrates substantial speed increase
Again, I'm not contradicting your claim that C will usually be faster, or that writing very fast programs in Haskell takes a lot of effort. I'm saying that programs have to be fast *enough* and correct *enough*, and when those goals are achieved, the question is how we can achieve them with a minimum of effort, and with a maximum of clarity.
it's obvious. why i don't write to everyone complaining about lack of some haskell features that i don't need it?
?) Probably not a mistake in those papers, that depends on what the authors wanted to illustrate. But clearly a mistake in a performance sensitive program, and clearly a mistake if you want to argue that Haskell is too slow to use for real programs.
i don't say that haskell is slow for real programs. i say that idiomatic haskell is much slower than idiomatic C and these papers demonstrates how much, for simple computation-intensive loops -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com