Live data from Hacker News

Performance comparison: counting words in Python, C/C++, Awk, Rust, and more

benhoyt.com

1–10 of 234 posts

Re: Performance comparison: counting words in Python, C/C++, Awk, Rust, and more

#6
See also a different comparison (on ~the same problem) at StackExchange: https://codegolf.stackexchange.com/questions/188133/bentleys...

(Copying from my comment the last time this was posted: https://news.ycombinator.com/item?id=26467684)

There's also a nice book "Exercises in Programming Style" about just this problem.

Re: Performance comparison: counting words in Python, C/C++, Awk, Rust, and more

#7
> Incidentally, this problem set the scene for a wizard duel between two computer scientists several decades ago. In 1986, Jon Bentley asked Donald Knuth to show off “literate programming” with a solution to this problem, and he came up with an exquisite, ten-page Knuthian masterpiece. Then Doug McIlroy (the inventor of Unix pipelines) replied with a one-liner Unix shell version using tr, sort, and uniq.

Since this writing and other linked resources present only one side of the affair, I will mention: the presentation in Pearls was quite unfair to Knuth, and the conclusions commonly made of it somewhere between moderately and entirely unsound. (That is, as conclusions from the paper. I speak of unsoundness of logic only: these conclusions may be supportable from other sources.)

Knuth was challenged to demonstrate literate programming, and so that was what he demonstrated. He showed building something from the ground up assuming a very minimal environment, with problem analysis and all: of course that ended up more verbose than a Unix pipeline that glosses over problem analysis and starts with most of the tools you need to make a probably-acceptable solution!

McIlroy himself admitted a few years later that he had been “a little unfair” to criticise on engineering grounds what had only been an illustration of technique. Even in the paper, Bentley did admit a degree of culpability for this mismatch in his “criticism of programs” paragraph. (“He admires the execution of the solution, but faults the problem on engineering grounds. (That is, of course, my responsibility as problem assigner; Knuth solved the problem he was given on grounds that are important to most engineers-the paychecks provided by their problem assigners.)”)

But I do wish that Knuth had been given the opportunity to write a review of McIlroy’s review, for simultaneous publication.

Re: Performance comparison: counting words in Python, C/C++, Awk, Rust, and more

#9

Wow. Swift, touted as "safe by design and (...) runs lightning-fast"[1] is more of a screw-up than I thought. Almost twice as slow as Lua and behind even Pascal and Forth. [1] https://developer.apple.com/swift/

It's a single implementation, I wouldn't put too much on it. I can definitely write a C++ implementation that's slower and less optimised than most of those results, particularly if I was using Boost.

iPhone and Mac apps run pretty well in my experience, and Swift is definitely faster (in general) than Python at least. There were some serious considerations to port over ML libraries to Swift due to its ease of use, similar to Python, while providing much better execution speed.

Re: Performance comparison: counting words in Python, C/C++, Awk, Rust, and more

#10
In this type of blog post with comparisons including many languages, you usually see some unatural approach for your favorite language.

However, in this case, the Python example is idiomatic.

Since the articles calls for better approaches, I would suggest to take the opportunity to use the walrus operator and rsplit() for the optimized version. Something like this:

    reminding = ""
    c=Counter( )
    while (chunk := sys.stdin.read(64 * 1024)):
        pre, post = chunk.lower().rsplit('\n', 1)
        c.update((reminding + pre ).split())
        reminding = post
It should not affect performance too much, and the code gets more expressive.

However, the performances will be quite different depending of the python version you use. Interestingly, Python 3.11 beta, which comes with a lot performance tweaks, is slower for this exercice, while being reported to be faster on real life tasks.

Post reply on HN