Bulat Ziganshin
but problem - not mine, but for haskellers, is that some people said that ghc can generate code that is as fast as gcc one. it will be stupid if someone will start to write say mpeg4 codec and after year of work will find that it need 100 Ghz cpu to work. it's why i made this test, which you are trying to fool now. people that will believe your "arguments" instead of checking numbers may spend a lot of time meaningless. but it's doesn't matter for you, fanatics
/me takes a breath Well, _if_ I was going to write a mpeg4 codec, I'd be starting of in Haskell, anyway, to get to terms with the algorithm. After being satisfied, in terms of quality and big-O, I'd start investigating how to do it as fast as possible. Most likely, that would include serious amounts of C. In any case, I could point out non-perfect optimisation to the ghc devs. Out of those devs, someone will know why the current optimisations don't work for that case. As soon as the devs know why it doesn't work, chances are that someone else does, or, at least, is curious enough. I certainly don't know jack about the latter topics, I only know that _my_ code doesn't work as it would, were the world perfect. From that, I can infer with certainty that I don't know jack about how long it would take the ghc devs to enable me to replace C with the original Haskell. I only know that, most likely, I couldn't do it faster. Therefore, I just take the chance, open a ticket, and see what happens. After all, if I _don't_ open a ticket, chances that it gets fixed are lower, if not non-existent. Doing all this, I couldn't care less about what you or Don say. One says that you can't have fast Haskell, the other one says that you can, the first one says that yes, in that case, but not in that, the second continues saying well but if you do that, then the first one goes but that doesn't count... I don't care: Both are right, from their own perspectives. If you make predictions on how people are going to interpret something someone says, you're bound to be mistaken. You won't make me believe that ghc can't produce fast code, and Don won't convince me that I will be able to, in every case. What'll make me happy, right now, isn't random test cases, but a test framework that lets us all reproduce each other's experiments in a controlled -- and thus numerically comparable without discussion -- environment. The current state of things leaks information, and isn't able to catch possible regressions, at all. Still, I could not care less about ghc's performance, right now: I'm much more concerned with high-level stuff, right now. What I _do_ know, is that all the results, collected in this thread, won't mean a thing the instant we get another ghc release, and that noone will be able to update the results without wading through flames, again. So, here's my advice: If you care about performance and best-possible communication of its state to the community, set up a page, in the spirit of the language shootout, that compares haskell compilers vs. chosen c and fortran compilers, in a variety of cases. Did I mention that we need automated benchmark comparisons? -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.