I love using the UNIX shell (pipes and programs that do "one thing well") to the point where it hurts my ability to improve at other other languages. But sometimes all you need is a throwaway command to do something once, not a beautifully optimized function that will be written, improved, compiled, profiled, reoptimized and then executed a billion times. The utter tersity of a bash one-liner just tickles me.
Performance comparison: counting words in Python, C/C++, Awk, Rust, and more
91–100 of 234 posts
Re: Performance comparison: counting words in Python, C/C++, Awk, Rust, and more
#92Earlier quoted context omitted.
Ad uft8: it would change the problem only if the definition of word breaks changed. E.g., if a word break is defined by whitespace, then it probably doesn't.
What happens when the ASCII character for space is embedded within a multibyte UTF-8 codepoint?
Such "overlong" encodings are not valid UTF-8.
Re: Performance comparison: counting words in Python, C/C++, Awk, Rust, and more
#93What code was used for Common Lisp? I'm guessing a well written version would be in the top contenders for speed.
Re: Performance comparison: counting words in Python, C/C++, Awk, Rust, and more
#94How about extending this to comparing programming language efficiency from a developer's standpoint, looking at bytes of code, versus the execution time? I took the source code file size from the repository, and the runtime from the blog post. Then I made an arbitrary overall "PAIN SCORE" (lower is better) by multiplying code size * runtime. I suggest this is a worthwhile metric simply because lower is better on both…
It would probably be prudent to strip comments before measuring the code sizes:
I did not check all files, but noticed that the simple rust code consists of about 60% comments (in terms of bytes), mostly due to a verbose blurb. It also spends about 15% of the non-comment bytes on printing nicer error messages, which is an interesting choice for a micro-benchmark. The simple C and FORTH versions similarly have a lot of comments.
Meanwhile a lot of the other files have very few or no comments.
Re: Performance comparison: counting words in Python, C/C++, Awk, Rust, and more
#95Doesn't the Unix Shell implementation break the "threading" constraint, in that each program in the pipe will have a main thread each, and all the programs will run concurrently? Or should the "threading" constraint really have been stated as "you can use multiple threads, but only if they all have their own address space"? Alternatively, given the multi-core capabilities of even budget/mobile/small systems these day…
If I were doing the benchmark, I would just run it on a VM with a single physical core. There are good reasons for comparing single threaded performance since it may not be necessary or desirable to scale that way. For example, suppose it's a wc API or something; limiting each request to a single thread can be better since you get fairer scheduling and less data sharing which is almost always better for multiprocessing. Even shared immutable data can cause problems since the CPU may not realize the data is actually immutable.
I agree GPUs would probably do well on this problem, though it depends on how expensive the memory copying to/from the GPU ends up being. However, if you are going for all our performance, it seems like you could use SIMD like memchr or something.
Re: Performance comparison: counting words in Python, C/C++, Awk, Rust, and more
#96It's a bit of a shame that Rust's stdlib doesn't have a "fast but less safe" hasher. It's one of the easiest performance optimizations in my experience because it's very rare that an attacker controls input to your hashmap in a way that can actually lead to a DOS.
Not that it doesn't happen, it's just not something I've run into.
Just today I was testing out the performance difference hashing some Scylla queries and got nearly 2x faster hashing moving to fxhash.
Re: Performance comparison: counting words in Python, C/C++, Awk, Rust, and more
#97Earlier quoted context omitted.
> But IMHO AWK takes the crown here. :) Agreed! AWK is still the king of this stuff. For tasks like this, I kinda think AWK is nigh-unbeatable: so simple to write, so obvious what's going on (even if you've never seen any AWK program before, you're probably going to be able to figure out what's going on there), and decently performant. AWK is the bee's knees.
On the other hand, I'm rather surprised that the Go version is almost as long and opaque as C.
Are you looking at the "simple" or the "optimized" versions? For the optimized, yes, the Go one is very similar to the C. For the simple, idiomatic version, the Go version [1] is much simpler than the C one [2]: 40 very straight-forward LoC vs 93 rather more complex ones including pointer arithmetic, tricky manual memory management, and so on.
[1] https://github.com/benhoyt/countwords/blob/c66dd01d868aa83dc... [2] https://github.com/benhoyt/countwords/blob/c66dd01d868aa83dc...
Re: Performance comparison: counting words in Python, C/C++, Awk, Rust, and more
#98How about extending this to comparing programming language efficiency from a developer's standpoint, looking at bytes of code, versus the execution time? I took the source code file size from the repository, and the runtime from the blog post. Then I made an arbitrary overall "PAIN SCORE" (lower is better) by multiplying code size * runtime. I suggest this is a worthwhile metric simply because lower is better on both…
I would expect the AWK version to have very low pain despite its reputation. This is the sort of problem that AWK is well optimized for.
Re: Performance comparison: counting words in Python, C/C++, Awk, Rust, and more
#99This was always my approach when I had do “leetcode whiteboard interviews”.
Start with something not too far north of FizzBuzz but with a ton of scope to progressively enrich the problem until the clock runs out.
At $BIG_CO du jour people tend to talk about how much “signal” an interview produces, and starting somewhere that a meaningful number of candidates can’t do anything with offers very little “signal”, likewise very little Shannon information.
Great article!
Re: Performance comparison: counting words in Python, C/C++, Awk, Rust, and more
#100I like the OCaml version. It's both very easy to read and comes out really well in the benchmark. I also looked at the "simple" Zig version, which came out really well in the benchmark, and to me it didn't look simple at all. It seems you need to make a lot of low level details explicit. But IMHO AWK takes the crown here. :)
TFA only talks about gawk, though, making this comparison meaningless ie. you can't benchmark languages but only language implementations . Same goes for other programming languages ofc unless those have only a single implementation. mawk is an order of magnitude faster than gawk, and gawk isn't even the default on many Linuxen.
> TFA only talks about gawk, though, making this comparison meaningless
Not exactly! To quote from TFA (I'm the author):
> Another “optimization” is to run it using mawk, a faster AWK interpreter than gawk. In this case it’s about 1.7 times as fast as gawk -b. I’m using mawk in the benchmarks for the optimized version.