[Haskell-cafe] Re: speed: ghc vs gcc

[Achim Schneider]

Bulat Ziganshin <bulat.ziganshin at gmail.com> wrote:

> 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.