Our distributed NewSQL database project actually uses three of them, Go, Rust, and C++, for different layers. There are pros and cons for each of them, but it still challenge to maintain three languages in a one system development. Performance wise, C++ and Rust are good, coding wise Go is easiest but Rust is kind of having best practice.
Performance comparison: counting words in Python, C/C++, Awk, Rust, and more
31–40 of 234 posts
Re: Performance comparison: counting words in Python, C/C++, Awk, Rust, and more
#32I 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.
Can we move past the whole "it is not really python to use libraries written in C", especially when talking pure stdlib python?
Python is basically a DSL for C extensions. That is the whole point. It would be like criticizing any compiled language for essentially being a DSL for machine code, and not "Real Instructions".
Python's ability to interop with pre-built, optimized libraries with a lightweight interface is arguably its greatest selling point. Everyone and their dog knows purely interpreted CPython is slow. It doesn't need to be pointed out every single time python performance is brought up unless literally discussing optimizing the CPython vm.
Re: Performance comparison: counting words in Python, C/C++, Awk, Rust, and more
#33For 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 functions are available on byte slices [u8] where ASCII could be what you have (whereas their Unicode cousins are not available on byte slices).
Re: Performance comparison: counting words in Python, C/C++, Awk, Rust, and more
#34My takeaway is that unoptimized c++ is pretty close to the same performance as JavaScript.
Wild.
Re: Performance comparison: counting words in Python, C/C++, Awk, Rust, and more
#35surprised to see swift 4 times as slow as non-optimized go.
Anyone has an explanation ?
I know the swift string type is really complex, but i always assumed it was at least performing well..
Re: Performance comparison: counting words in Python, C/C++, Awk, Rust, and more
#36This 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 meaningful if the runtime is not dominated by library functions, or if one admits it's really a standard library performance comparison, not a language comparison.
Re: Performance comparison: counting words in Python, C/C++, Awk, Rust, and more
#37For 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.
Sure, but is it changing the problem to something easier than what the other languages are already doing, or to something more similar? I'd imagine the C code is basically just using byte arrays as well, for instance.
Re: Performance comparison: counting words in Python, C/C++, Awk, Rust, and more
#38You included Awk in the title, but omitted Go, really?
Re: Performance comparison: counting words in Python, C/C++, Awk, Rust, and more
#39surprised to see swift 4 times as slow as non-optimized go. Anyone has an explanation ? I know the swift string type is really complex, but i always assumed it was at least performing well..
Reading anything at all into the relative performance of these programs written by different people which are all doing radically different things seems like a gigantic waste of time.
Some of these “simple” versions are custom-specifying allocators to minimize memory overhead and doing highly optimizable ASCII value manipulations and doing byte-equality on strings, rather than go through slower Unicode libraries. The “simple” Swift version is doing nothing at all to avoid generating many allocations/deallocations and running fully Unicode-aware algorithms to lower the input and perform Unicode-normalized string comparisons, it’s totally apples-to-oranges stuff.
Re: Performance comparison: counting words in Python, C/C++, Awk, Rust, and more
#40You 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.