Making Rust as Fast as Go
christianfscott.com
Making Rust as Fast as Go
1–10 of 211 posts
Re: Making Rust as Fast as Go
#2Missed chance to shorten title to "Making Rust Go Fast" :-)
Re: Making Rust as Fast as Go
#3The Rust version uses `target.chars().count()` to initialise the cache, while the Go version counts up to `len(target)`. These are not equivalent: the Rust version counts Unicode code points, the Go version counts bytes.
I am confused by the implementations, although I have not spent any time testing them. Both versions contain a mix of code that counts bytes (`.len()` and `len(...)`) and Unicode code points (`chars()` and `[]rune(...)`). My guess is that the implementation might not work correctly for certain non-ASCII strings, but I have not verified this.
Of course, if only ASCII strings are valid as input for this implementation then both versions will be a lot faster if they exclusively operate on bytes instead.
Re: Making Rust as Fast as Go
#4TLDR for people who didn't read:
The speed difference came from the allocator.
Rust switched from jemalloc to the system allocator per ticket #36963[0] for various reasons (like binary bloat, valgrind incompatibility, etc...).
Go uses a custom allocator[1] instead.
To make 'Rust Go fast' (pun intended), one can use the '#[global_allocator]' to use a custom allocator (in this case, with the jemallocator crate) to make allocations fast again.
Re: Making Rust as Fast as Go
#5I recently did some experiments with creating small static Rust binaries, custom linking, no_std et cetera. A lot of stuff around that kind of thing is unstable or unfinished, which might be somewhat expected. But I’ve also come to the conclusion that Rust relies on libc way too much. That might be fine on Linux, where GNU’s libc is well-maintained, is a bit questionable on MacOS (as seen in this article) and is a a complete distribution nightmare on Windows (in no small part due to a series of very questionable decisions by Microsoft).
My understanding is that Go doesn’t use the libc at all and makes system calls directly, which IMO is the correct decision in a modern systems programming language that doesn’t want to be limited by 40 years of cruft.
Re: Making Rust as Fast as Go
#6Assuming this was run on a 64bit system, the Rust version seems to be allocating and zeroing twice as much memory as the Go version.
edit: this has been pointed out as incorrect, Go ints are 8 bytes on 64bit systems -- thanks for the correction!
let mut cache: Vec = (0..=target.chars().count()).collect();
let mut cache: Vec = vec![0; target.len()];
cache := make([]int, len(target)+1)
for i := 0; i So between doing more work and worse cache usage, it wouldn't be surprising if the Rust version was slower even with the faster allocator.
Re: Making Rust as Fast as Go
#7The Rust version uses `target.chars().count()` to initialise the cache, while the Go version counts up to `len(target)`. These are not equivalent: the Rust version counts Unicode code points, the Go version counts bytes. I am confused by the implementations, although I have not spent any time testing them. Both versions contain a mix of code that counts bytes (`.len()` and `len(...)`) and Unicode code points (`chars(…
Yes, especially because that changes it from constant time (strings know their length in bytes) to linear time (counting chars means a loop through the text.)
I was a bit suspicious of the conclusion, but didn’t dig in myself. I imagine this would be a much larger source of difference.
Re: Making Rust as Fast as Go
#8The Rust version uses `target.chars().count()` to initialise the cache, while the Go version counts up to `len(target)`. These are not equivalent: the Rust version counts Unicode code points, the Go version counts bytes. I am confused by the implementations, although I have not spent any time testing them. Both versions contain a mix of code that counts bytes (`.len()` and `len(...)`) and Unicode code points (`chars(…
Yep.
Here a Go playground example showing that the result is indeed wrong:
https://play.golang.org/p/vmctMFUevPc
It should output 3 but outputs 5 because each ö is two bytes, len("föö") = 5.
I would suggest using "range" to iterate over the unicode characters.
Re: Making Rust as Fast as Go
#9Could also try to use the smallvec crate in this case, which put small allocation on the stack https://docs.rs/smallvec/
Re: Making Rust as Fast as Go
#10Assuming this was run on a 64bit system, the Rust version seems to be allocating and zeroing twice as much memory as the Go version. edit: this has been pointed out as incorrect, Go ints are 8 bytes on 64bit systems -- thanks for the correction! let mut cache: Vec = (0..=target.chars().count()).collect(); which can be simplified as let mut cache: Vec = vec![0; target.len()]; vs cache := make([]int, len(target)+1) for…
Go int is 8 bytes