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
Performance comparison: counting words in Python, C/C++, Awk, Rust, and more
231–234 of 234 posts
Re: Performance comparison: counting words in Python, C/C++, Awk, Rust, and more
#232I'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.
Re: Performance comparison: counting words in Python, C/C++, Awk, Rust, and more
#233Earlier 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`
Re: Performance comparison: counting words in Python, C/C++, Awk, Rust, and more
#234Earlier 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…
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.