41–50 of 234 posts
> 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 w…
Re: the Rust optimized implementation, I was able to get ~20-25% better performance by rewriting the for loops as iterators, using Rust's byte range pattern matching, and a buffered writer, which seems crazy, but it's true. I chalked it up to some crazy ILP/SIMD tricks the compiler is doing. I even submitted a PR[0], but Ben decided he was tired of maintaining and decided to archive the project (which fair enough!).…
Very nice. That’s in fact really clean, and (at least to me) indeed surprising. As rejection reasons go, “I wanted to name-drop person X” is interesting. But as you said, that’s the maintainer’s decision to make.
> 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 w…
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
Also of note is that most CPUs of the day didn't execute instructions orders of magnitude faster than bandwidth to main memory, as is the case today; it was early days for worrying about making algorithms "cache aware". So, for instance, there was no big penalty for "pointer chasing" in linked lists as there is today. Additionally, the severe memory size limits affected various time vs. space tradeoffs in algorithm design.
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…
The problem specified declares the words we're counting are ASCII: > ASCII: it’s okay to only support ASCII for the whitespace handling and lowercase operation UTF-8 (quite deliberately) is a superset of ASCII. So a UTF-8 solution is correct for ASCII, but a bytes-as-ASCII solution works fine in Rust if you only need ASCII. This is why Rust provides ASCII variants of a lot of functions on strings, and the same functi…
That's a somewhat specific list -- at least I didn't read that as a general "the program can assume that the input is only ASCII".
But then, the author seems to have accepted solutions that crash on non-UTF8 sequences and ones that byte-compare them, so probably either behavior was meant to be fine. I just don't get that from this rule.
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…
You included Awk in the title, but omitted Go, really?
Indeed. The original title is: > Performance comparison: counting words in Python, Go, C++, C, AWK, Forth, and Rust. Which means the submitter actively chose Go to be removed from the title. Judging from their post history they are aligned with Rust community.
This site makes Chrome (Android, current) stop responding.
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.
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/
Swift is in the same or better performance bracket then C#/Java and unsafe usage can be close to performance of C (maybe 1.3-2x slower). I'm not sure about ranting for poor single test results :P
It's not the only benchmark in town and it needs to be taken with a grain of salt, but so does every benchmark.
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, s…