71–80 of 234 posts
Earlier quoted context omitted.
The original title is 2 characters over the HN title length limit. I suspect they dropped "Go" first, because it's the language which has a 2-letter name, and they they editorialised it further to hint that there are more languages.
Leaving Awk over the vastly more popular Go, hints a more probable and frequent behaviour: bias. Removing any of them would suffice.
For those curious about Rust optimization, the “optimized” version makes three changes compared to the “idiomatic” version: * It uses byte strings instead of UTF-8 strings. In my opinion, that’s not an optimization, that’s changing the problem. Depending on the question you’re asking, only one of the two can be correct. * It uses a faster hash algorithm. It’s not the first time this came up in a benchmark article. Ru…
To be fair, that's what the C version does as well.
I 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. :)
mawk is an order of magnitude faster than gawk, and gawk isn't even the default on many Linuxen.
Earlier quoted context omitted.
1986 was very early days for modern operating systems. I suspect that the hardware environment(low resource) would be surprising to many phone owners here. So the efficacy had to do with the tools low-level bindings, too
Indeed. In 1986, Knuth was exclusively using the SAIL DEC10, running the WAITS OS. This environment limited him to approximately half a megabyte of data space (heap plus stack plus globals), and half a megabyte of code space. All statically linked, so all library and runtime stuff had to fit. Also of note is that most CPUs of the day didn't execute instructions orders of magnitude faster than bandwidth to main memory…
Some of these efficiency gains are remarkable. Most of the code I write is just the quickest way to write a mundane function. Really curious if you went into a huge tech co and devoted ~10% of SWE time solely to optimization of code base what the energy savings would be.
The real money is in huge non-tech co, or medium tech co. You could walk into a goldman sachs type of operation and point out savings in CPU time that would be 90-99%. But they're not going to care, because their corporate structures aren't wired to observe and act on such things.
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.stdi…
Your code assumes there is at least one newline in each 64K chunk, and assumes there are no words past the final newline. It will fail on "abc" and give the wrong answer for "abc\ndef". I prefer rpartition over rsplit to handle first case, and the loop-and-a-half construct instead of the while+walrus operator to handle the second, as in this modified version of your code: remaining = "" c=Counter( ) while True: chunk…
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 days (even the Rasberry Pi 4 has a quad-core CPU), isn't restricting the implementation to a single thread a weird artificial limitation in 2022? Also, a GPU-based implementation would be interesting, and GPUs most of their power from their massively parallel core architecture.
How 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…
Previously —
"Completely Random and Arbitrary Point System!, or CRAPS![TM]"
https://web.archive.org/web/20010124100400/http://www.bagley...
Currently —
fwiw https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
> Sorting only by code size
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Earlier quoted context omitted.
Leaving Awk over the vastly more popular Go, hints a more probable and frequent behaviour: bias. Removing any of them would suffice.
The author maintains an AWK implementation: https://github.com/benhoyt/goawk
For those curious about Rust optimization, the “optimized” version makes three changes compared to the “idiomatic” version: * It uses byte strings instead of UTF-8 strings. In my opinion, that’s not an optimization, that’s changing the problem. Depending on the question you’re asking, only one of the two can be correct. * It uses a faster hash algorithm. It’s not the first time this came up in a benchmark article. Ru…