[Haskell-cafe] Re: Re[2]: What's the deal with Clean?

[John Lato]

On Thu, Nov 5, 2009 at 11:25 AM, Bulat Ziganshin
<bulat.ziganshin at gmail.com> wrote:
> Hello John,
>
> Thursday, November 5, 2009, 1:59:14 PM, you wrote:
>
>> I hope you don't mind me asking this, but when you state that
>> "idiomatic haskell is much slower than idiomatic C", what do you mean
>> by "much slower"?  2 times?  3 times?  20 times?  Order of magnitude?
>
> it depends on task, of course. with a number crunching code, it may be
> hundreds or even thousands, but this application area isn't typical
> for haskell, after all. for typical apps like text processing it may
> be dozens. when we are going into real life, use of FFI libraries and
> OS calls makes difference even smaller, so i think that practical
> difference is 3-10 times, in most cases

Ok, this is a reasonable starting point.

>
>> I'm not going to disagree with you, however it seems to me the gap is
>> closing.
>
> except for BS library, i don't see too much practical improvements.
> GHC by itself was made ~20% faster with pointer tagging
>

I'm really only interested in looking at data of comparisons here.

>> My opinion may be colored by having just examined Masayuki
>> Takagi's SPH code, which I considered very idiomatic Haskell and for
>> me performed equivalently to his C++ code with the changes I detailed
>> in an earlier email (none of which involved any substantial changes to
>> his code or style in my opinion).
>
> i don't know why his haskell code is so fast - it may be due to
> improvements in ghc about compiling tight loops, unoptimal C code,
> bounds placed by memory speed. well, i know one problem in his C
> compilation - he doesn't used -O3 -fexcess-precision and other funny
> optimization tricks

True enough.  If I did so with ghc, it's only fair to give g++ the
chance as well.  Although when I tried it with -O3 -ffast-math, I
didn't see any gross changes in runtime speed gained from -O2.  There
may be benefits, but it would take statistical analysis to determine
their significance.

Also, you may not believe it, but the results I posted were for the
first unfolding thresholds I picked.  Those could probably be tuned
further as well.

>
> there is difference in treating good and bad comparisons. when someone
> shows that haskell is much slower, there are lot of suggestions how to
> improve the code, add strictness, use other libs, apply tricky
> compiling options, even unroll loops by hand. when someone shows small
> gap between C and Haskell, noone checks that C code is optimized as
> much as possible. of course, it's mainly because many haskellers can't
> optimize C code. but this should lead to the conclusion "i'm
> incompetent in comparison" rather than "haskell is fast"
>

Re: most optimal C code

I will agree that for most discussions on this list nobody checks that
the C versions are as optimal as possible, however I would suggest
it's for a different reason.  Many C libraries and programs are
already widely available in a highly-optimized form, often as a result
of years of work.  Programs like the shootout lead to a similar effect
(that is, Haskellers don't bother checking that C is optimized because
the C submitters will be doing that).  When doing comparisons against
code like that, I think it's fair to assume that the C versions are
already, if not as fast as possible, within a close enough percentage
to establish a fair benchmark.

For this specific case, I would look at it slightly differently.  The
C++ version has a level of performance the author was satisfied with.
It presumably isn't optimized to the hilt, but it's very readable.
The Haskell version is similarly readable, however the author wasn't
happy with the performance (I never saw anything as poor as originally
reported, BTW) and asked how it could be improved.  I made a few
suggestions, as did you and others, none of which IMO make the code
non-idiomatic Haskell, and none of which takes more than a few minutes
to implement.

Could the speed of the C++ version be improved?  Probably so, but it
wouldn't look as nice.  This is probably true for the Haskell code
too.  Doing either one would likely take a significant amount of work.
 Neither one may be most optimal, but I would argue that the C++ and
Haskell (with suggestions from this list incorporated) programs are
basically equivalent in being idiomatic to the language and
performance.  You could say that both are essentially optimized to the
same standard, which is good enough for the task at hand.

Even without any changes, for me the starting difference was roughly
50%, which is under your threshold of 3x as "much slower".  Most of
that difference was made up with compiler flags, whereas I doubt that
any flags you pass to g++ (on top of -O3) will  yield anything close
to a 40% improvement.

Cheers,
John