Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

benhoyt.com

Post reply on HN
Print view View original

21–30 of 234 posts

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

#21

Post by codeflo »

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. Rust’s decision to use a DOS-safe hash by default (and not provide a fast algorithm in the std, like other languages do) really seems to hurt it in that kind of microbenchmark.

* It uses get_mut+insert instead of the more convenient HashMap::entry method, because the latter would require redundantly allocating the key even in the repeat case. I’ve hit this problem in the past as well. Maybe the upcoming HashMap::raw_entry_mut will make this kind of optimization cleaner.

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

#22

Post by __marvin_the__ »

FpUser wrote: post #12

I would not call it performance comparison at all. When Python call functions written in C it is not Python's performance. Write those functions using plain Python and then see the results. Sure for this basic example in the article it does not matter from a practical standpoint. But when you need to step away from canned cases suddenly Python's performance sucks big time.

Python's `collections.Counter` is written in Python and is a subclass of the builtin `dict` type. I don't think it's comparable to something like using `pandas` to solve the problem.

https://github.com/python/cpython/blob/main/Lib/collections/...

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

#23

Post by gernb »

machinekob wrote: post #16
gary17the wrote: post #5

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

Latner himself (creator of Swift) said Swift had speed issues because of ARC that they were hoping to solve with better code analysis. Did they?

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

#24

Post by yakubin »

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. :)

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

#25

Post by codeflo »

mustache_kimono wrote: post #20

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.

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

#26

Post by [deleted] »

gernb wrote: post #23
machinekob wrote: post #16

Earlier quoted context omitted.

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

Latner himself (creator of Swift) said Swift had speed issues because of ARC that they were hoping to solve with better code analysis. Did they?

[deleted]

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

#27

Post by coldtea »

codeflo wrote: post #21

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…

>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.

For tons of questions, both can be correct.

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

#28

Post by georgelyon »

gernb wrote: post #23
machinekob wrote: post #16

Earlier quoted context omitted.

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

Latner himself (creator of Swift) said Swift had speed issues because of ARC that they were hoping to solve with better code analysis. Did they?

They have been improving this steadily (I would argue it is rarely an issue nowadays, and there have always been simple workarounds), but there’s no reason a solution to the problem mentioned in the article should need to use ARC, and should use structs/protocols instead (which don’t use reference counting). I’ve seen a lot of Benchmarks that rate Swift poorly because of this.

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

#29

Post by OskarS »

yakubin wrote: post #24

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. :)

> 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.

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

#30

Post by tialaramex »

gary17the wrote: post #5

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/

I don't know that I'd characterise it as a "screw up" based on one random person's solution to one particular problem.

In particular the "simple" solutions, which is all that's offered for Swift, will be whatever was most idiomatic/ obvious to a programmer of potentially quite variable quality.

It's unfortunate, I think, that there are "simple" solutions for some languages which have had performance revisions. If you needed an hour, or a friend, or even a community to "hint" how to improve it that wasn't the simple solution.

[ For example I feel like the Rust might be faster asking for ASCII lowercase, and using the unstable (not order-preserving) sort algorithm, but even if I'm correct such a change would logically be made to the optimised Rust, not the simple ]

Post reply on HN