Live data from Hacker News

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

benhoyt.com

231–234 of 234 posts

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

#231
post #201

Earlier quoted context omitted.

I think the interesting question there (and really any language comparison) is to compare the result of idiomatic implementations. Unfortunately, there is no clear answer on what is idiomatic, even with something like Python that is more opinionated than most on the question.

When there is "no clear answer on what is idiomatic", we are left with uninteresting "yes it is" / "no it isn't" Dead Parrot assertions. http://montypython.50webs.com/scripts/Series_1/53.htm

I think the best way forward on the idiom question is to accept that we can't have a competitive/adversarial benchmark suite where idiom is a factor. I think you really need one author, or maybe a group of colleagues who trust each other, to write the whole suite and make their own choices about what idiom means to them. Folks who disagree with those choices can either write an article about how much performance you gain from making what changes, or just produce their own whole suite. Having a very high level comparison like "this is how languages stack up with these idiomatic choices, but this is a different chart with different choices" would be interesting, even though it would take more work to interpret it.

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

#232

I've checked with ClickHouse and the result is better than I expect... it runs in 0.043 sec. on my machine, which is faster than any other result. The code: SELECT arrayJoin(splitByChar(' ', lower(line))) AS word, count() AS c FROM file('kjvbible.txt', LineAsString) WHERE notEmpty(word) GROUP BY word ORDER BY c DESC FORMAT Null or: clickhouse-local --query "SELECT arrayJoin(splitByChar(' ', lower(line))) AS word, cou…

I forgot to multiply the file 10 times. When I do, the result is 0.209 sec. which is still better than every other result.

You are also using a language function to read the file. In the 'official' github implementations they have to accept the data line by line from stdin - stdin likely being slower than reading a file directly.

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

#233

Earlier quoted context omitted.

>it runs in 0.043 sec. on my machine, which is faster than any other result. Did you run the other benchmarks on your machine as well?

Yes (but only scripted, without compilation): `grep` | 0.03 | 0.03 | `grep` baseline; optimized sets `LC_ALL=C` `wc -w` | 0.18 | 0.25 | `wc` baseline; optimized sets `LC_ALL=C` SQL | 0.26 | | by Alexey Milovidov Perl | 1.22 | | by Charles Randall Python | 1.42 | 0.86 | Tcl | 5.30 | | by William Ross Shell | 9.66 | 1.79 | optimized does `LC_ALL=C sort -S 2G`

N.B. the Tcl script is absurdly inefficient. A single simple optimization cuts the run time in half.

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

#234
post #201

Earlier quoted context omitted.

When there is "no clear answer on what is idiomatic", we are left with uninteresting "yes it is" / "no it isn't" Dead Parrot assertions. http://montypython.50webs.com/scripts/Series_1/53.htm

I think the best way forward on the idiom question is to accept that we can't have a competitive/adversarial benchmark suite where idiom is a factor. I think you really need one author, or maybe a group of colleagues who trust each other, to write the whole suite and make their own choices about what idiom means to them. Folks who disagree with those choices can either write an article about how much performance you…

Seems that idiomatic is a matter of personal taste, used to arbitrarily accept or reject.

One way forward would be to ignore claims based on idiom, but measure how long it took to write a program that produced correct output.

Post reply on HN