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

161–170 of 234 posts

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

#161

Post by tobz1000 »

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!).…

These changes would prompt some additional remarks about the Rust implementation: most optimisations make code more verbose and less idiomatic, but in Rust it can sometimes be the opposite.

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

#162

Post by bornfreddy »

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 is the case, it would explain why python is so slow. In my experience the runtime speed of python is good enough for most purposes, but startup time is definitely slow.

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

#163

Post by dureuill »

compumike wrote: post #69

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…

Programming language efficiency from a developer's standpoint is not measured in bytes written in the source code, because typing characters is never the bottleneck when writing code.

Even if it were, most code isn't "fire and forget", and so for most code the cost is dominated by maintenance cost, which has more to see with reading than writing code.

Languages that are concise are so because they either express information very densely, or express less information (via for example ignoring error handling or making it implicit with exceptions). In practice I find that such languages are much harder to maintain, because the missing information has to be rebuilt by the reader.

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

#164

Post by norman784 »

compumike wrote: post #69

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…

Isn’t unfair to not count the runtime code size too for interpreted languages? Because for the compiled ones, they include all the necessary runtime in the executable.

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

#165

Post by kramerger »

> When optimizing this, the first thing to do is compile with optimizations enabled (g++ -O2). I kind of like the fact that with Go you don’t have to worry about this – optimizations are always on.

I think it is more fair to say that in Go optimizations are always OFF.

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

#166

Post by kramerger »

For performance comparison between languages, this article is not very useful. Nothing against the author, this task is simply impossible :)

Om the other hand the article is gold mine for learning performance analysis in different languages.

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

#167

Post by fauigerzigerk »

zX41ZdbW wrote: post #144

I've checked with ClickHouse and the result is better than I expect... it runs in 0.043 sec. on my machine, which is faster than any other result. The code: SELECT arrayJoin(splitByChar(' ', lower(line))) AS word, count() AS c FROM file('kjvbible.txt', LineAsString) WHERE notEmpty(word) GROUP BY word ORDER BY c DESC FORMAT Null or: clickhouse-local --query "SELECT arrayJoin(splitByChar(' ', lower(line))) AS word, cou…

>it runs in 0.043 sec. on my machine, which is faster than any other result.

Did you run the other benchmarks on your machine as well?

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

#169

Post by [deleted] »

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…

[deleted]

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

#170

Post by Too »

compumike wrote: post #69

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…

Extra pain score should be awarded for 2 character abbreviations, one character flags, mode switches, special character operators, difficult documentation, lack of error handling, missing type safety, difficulty of introspecting/debugging halfway through program, environment dependencies. Most of these weigh a lot more than just line count.
Post reply on HN