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

171–180 of 234 posts

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

#171

Post by camel-cdr »

oconnor663 wrote: post #90
HarHarVeryFunny wrote: post #36

This is a rather meaningless comparison, since the differences are going to be dominated by: 1) The choice of libraries/datatypes used for strings and word->count map 2) How the source file is split into words - probably library function again, although in C/C++ one could choose to implement a super-optimized low level version that would blow the others away IMO a performance comparison between languages is only mean…

Do you have a particular example problem in mind that might demonstrate language performance better? One of the Benchmark Game programs maybe?

What is there to benchmark between C++, C, Rust, or any other low level compiled language though? With any one of them you can essentially achieve the same assembly code generation, if you try hard enough.

In the end it either boils down to compiler optimisations or library implementations.

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

#172

Post by crummy »

bhauer wrote: post #17
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 only skimmed the article, but I suspect they are including the time necessary to spin up the executable and any runtime environment prior to executing the relevant code. "Lightning fast" can mean a lot of things, and it might not mean "executables start quickly."

If that were the case, that makes Java's results fairly impressive, given the JVM's slow start time.

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

#173

Post by zmmmmm »

It seems like this is just measuring a single pass at reading a file with about 100k words in it. I ran the benchmark and it finished almost instantly. So languages with startup overhead and warmup time (eg: JIT etc) will totally underperform here. Makes sense then why Java is almost identical between optimised and non-optimised versions.

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

#174

Post by arijun »

mustache_kimono wrote: post #160
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!).…

In case anyone is interested, I did an optimized, but much more simple, Rust implementation just today[0], which is faster than the optimized implementation on my machine. No indexing into arrays of bytes, no unsafe, etc., no "code golf" measures. Of course, credit where it's due -- these are simply tweaks to Andrew Gallant's code. Looks like idiomatic Rust, which I think is interesting. Shows there is more than one…

Out of curiosity, what's the difference in runtime when compared to Andrew's optimized version on your machine?

For your other solution, if the time save is consistent from your machine to OP's (a big if), the Rust solution bumps up to 4th place.

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

#175

Post by wscott »

fallingfrog wrote: post #56

Your Perl implementation is almost as fast as c++? Something weird is going on here. Maybe you are bottlenecked on disk read speeds or something.

This is what perl was made for and it is good at it. I was going to be very suspicious if Python or Ruby ended up faster. On this chart it it the fact that the simple C++ is so slow that is interesting.

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

#176

Post by pjmlp »

zmmmmm wrote: post #173

It seems like this is just measuring a single pass at reading a file with about 100k words in it. I ran the benchmark and it finished almost instantly. So languages with startup overhead and warmup time (eg: JIT etc) will totally underperform here. Makes sense then why Java is almost identical between optimised and non-optimised versions.

In what concerns Java, using AOT or JIT caches is also an option, however all these kind of benchmarks tend to reveal lack of knowledge of the Java ecosystem.

Same applies to .NET by the way.

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

#177

Post by moffkalast »

benhoyt wrote: post #97
moffkalast wrote: post #64

Earlier quoted context omitted.

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] ht…

Yeah I meant the optimized versions.

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

#178

Post by BiteCode_dev »

bhauer wrote: post #124
ppeetteerr wrote: post #104

Curious if anyone knows why the swift version is slow? Is it the casting from subsequence to a string?

As I wrote elsewhere in this thread (though I was downvoted), I suspect the reason is that this benchmark is measuring the total execution time of a single run of an executable. This would include any time spent by the executable to bootstrap its runtime environment, initiate a virtual machine, and whatever else it needs to do in addition to the relevant code at hand to process the string. Such a test will favor impl…

In that case, it would change the Python result dramatically as well.

But I don't think it would be fair: I use Python a lot, and if it's for scripting, you are happy with the fact it's very easy to write. However, it's slow to start, and you pay that each time you run the script.

To me, it makes sense in this exercice, which is heavily leaning toward scripting, we see the price of the VM start in the overall profiling.

Otherwise, let's use pypy, warm it up, a few 1000 times, and you may get closer to Go times.

But we don't use pypy for scripting.

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

#179

Post by jamincan »

camel-cdr wrote: post #171
oconnor663 wrote: post #90

Earlier quoted context omitted.

Do you have a particular example problem in mind that might demonstrate language performance better? One of the Benchmark Game programs maybe?

What is there to benchmark between C++, C, Rust, or any other low level compiled language though? With any one of them you can essentially achieve the same assembly code generation, if you try hard enough. In the end it either boils down to compiler optimisations or library implementations.

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.

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

#180

Post by benibela »

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/

>even Pascal and Forth.

Even?

Pascal is touted as being as fast as C

Post reply on HN