1. 18
    1. 25

      our implementation managed to beat wc by a factor of 5. Of course, that’s quite an unfair comparison: our implementation is hardcoded to count just the bytes, lines and words. … it’s better to consider what we’ve done last time as a proof-of-concept showing that it’s possible to achieve (and overcome) C-like performance on this task, even if with all those concessions.

      By the end, the OP has the Haskell taking 1.4 seconds, consistently 5-6x faster than the C version which, as said in the previous post, “presumably has decades of man-hours put into it.”

      …Except that’s not optimized C! An optimized version of wc is over a hundred times faster than the baseline version.

    2. 6

      Compares their solution to “Unix wc

      Links to GNU coreutils wc


    3. 4

      I’m not sure I understand the negative feedback this post is garnering—I think it’s quite cool to push the boundaries of a language you like to do something maybe it isn’t designed to do, even if it requires a bit of acrobatics. You can discover a lot in the process, doing a deep-dive into the libraries and the runtime, and I thought the resulting blogpost was informative. I don’t think the article was written in the spirit of antagonizing anybody at all. It felt more like a developer’s diary entry, documenting all the cool stuff they learned along the way. I would hate it they read through the comments on lobste.rs and felt demoralized by the responses? It doesn’t seem at all in the ethos of this community. The author doesn’t seem like they are dogmatically advocating for this approach to be the only approach; indeed, they seem like someone who would think it’s cool that there are multiple other ways to solve the problem in C and Haskell as well.

      1. 7

        I have two major qualms with it. The first is that it is artificially penalizing and misrepresenting the performance of the C version as it is comparing single byte character counting in Haskell to utf8 counting in the C version, and then further claims that the C version is heavily optimized to justify the comparison with heavily optimized and atypical Haskell.

        My second, and bigger, annoyance is just the unwillingness to commit to idiomatic Haskell. I think Haskell can produce cleaner or easier to reason about code, and I think there are things that you can get from the lazy evaluation, etc. This is a general problem I have with most of these Haskell vs. C posts - that they are discarding the things that make Haskell interesting or compelling in order to meet the perf of C that is often not making use of similarly atypical code. I’d rather see idiomatic and easy to understand Haskell that performs reasonably close to C to show how Haskell can be better than C.

        I also dislike the tendency to forcibly and globally disable non-strict evaluation which is a reasonably core language feature for Haskell - I’d rather that their code used selectively strict types or expression eval.

        1. 1

          What is idiomatic Haskell, besides a set of personal preferences we all have about programming in Haskell that necessarily differs from person to person? Especially when the author of the OP is using the GHC strictness features in the expected way – as a quick, no-hassle way to get performance wins that’s accessible to a newcomer. spj, the Dumbledore of Haskell, has talked about how laziness isn’t as fundamental to the design of Haskell as much as purity and typeclasses are. Haskell is a big tent!

          If there were a glut of Haskell vs. C blogposts on lobste.rs, sure, I’d find it annoying that each one used strict, imperative Haskell would be annoying. But there’s hardly any blog posts about Haskell these days! The attention the language had back in the 2010s is gone. Big contributors to the Haskell-verse, like kmett and ezyang and bos, have moved on. This is the thing I always found kind of frustrating about the Haskell community. Shouldn’t the goal be to promote Haskell in as many as ways as possible, and to encourage new people (I’m assuming the OP was written by a newcomer) to use the language in any ways they see fit? Instead, there’s quibbling and nitpicking. I still remember all the old arguments about how lenses compose backwards, when lenses solved a real problem Haskell had at the time (the inability to update deeply nested data structures in an elegant way). It’s just a programming language. New people will write unidiomatic Haskell, and that’s fine; idiomatic Haskell doesn’t even really exist, and that’s fine too.

    4. 4

      Meta: @puschx has already updated the title as per mod log so suggest feature is no longer applicable. Please append “(2020)” to the title.

    5. 3

      That looks like code that is more complicated than basic C code, aggressively uses monadic evaluation (so it’s essentially pulling “Haskell is the best imperative language” nonsense), disables strict evaluation, etc to get to some semblance of the performance of C (though C++ could do everything that they suggest cleanly more easily, and more understandably).

      The benchmarks also appear to decide comparing the performance to a version of wc that is told to handle utf-8, without handling utf8 themselves.

      We could compare to what I assume is some BSD version of wc: https://opensource.apple.com/source/text_cmds/text_cmds-68/wc/wc.c.auto.html

      That’s 193 lines of Haskell with no comments, no license, using external libraries for command line parsing, etc vs. 292 lines of C that does nothing special, uses no tricks, includes the license, command line parsing, and even comments.

      Finally as @hwayne says the standard versions of wc are not heavily optimized. Traditionally wc and similar have been IO bound, so performance of the code itself has not historically been relevant. Actually optimized C code destroys the Haskell.

      I wish Haskell fans would stop trying to write contorted Haskell to “compete” with C cpu performance. Instead demonstrate that Haskell can be used to implement the same functionality in less or easier to understand code.

      1. 1

        Haskell is the best imperative language nonsense

        In what world is this nonsense?

        1. 3

          (1) obviously a subjective claim, that I at least disagree with; but

          (2) If you take the entire context and the quotation marks rather than reflexively interpreting this as an attack on Haskell, it should be possible to understand that this isn’t an attack on Haskell as an imperative language, but rather an attack on articles that compare writing non-idiomatic haskell, and throwing away most functional language features, in order to match a non-haskell imperative language.

          Like I said at the end - I’m uninterested in how you can contort and micro-optimize haskell into something not at all Haskell-like in the attempt to match performance of some imperative language, because I can contort and micro-optimize the imperative language as well. It is vastly more interesting to see how to make a good idiomatic implementation of something that might not be as fast, but is clearer, or smaller, or something.

          What this article is meant to (?) show is that Haskell can be as fast as C. What it actually conveys is that getting Haskell performance to match unoptimized C code requires a lot of code (in the context of people saying haskell requires much less code), the code is complex, and the code isn’t like any normal haskell so it’s not necessarily going to be maintainable by someone else even if they do know haskell already.