npub19z…spj90 on Nostr: Been recording some profiles to try to explain _why_ my Rust translations of C ...
Been recording some profiles to try to explain _why_ my Rust translations of C programs tend to default to being faster.
Here's an unexpected culprit: strlen/strcmp.
The "natural" string representation in C is a char* pointing to a buffer that ends in a NUL (ASCII 0). To determine its length you have to crawl along it to find the NUL. To compare two strings, you need to do the same. In particular, because strcmp's return value isn't just a flag, but an integer giving the lexicographic relationship between the two strings ... it can't early exit if the lengths differ.
The "natural" string representation in Rust is a &str, which combines a pointer and a length. Finding the length is a constant-time near-no-op; comparing two strings for equality can trivially early-exit.
This might sound trivial, but profiles suggest it's a significant factor in wartcl being 4x faster than partcl across the board. In part, I suspect a lot of C programs do a lot of redundant strlen-computation unintentionally.
#rustlang
Here's an unexpected culprit: strlen/strcmp.
The "natural" string representation in C is a char* pointing to a buffer that ends in a NUL (ASCII 0). To determine its length you have to crawl along it to find the NUL. To compare two strings, you need to do the same. In particular, because strcmp's return value isn't just a flag, but an integer giving the lexicographic relationship between the two strings ... it can't early exit if the lengths differ.
The "natural" string representation in Rust is a &str, which combines a pointer and a length. Finding the length is a constant-time near-no-op; comparing two strings for equality can trivially early-exit.
This might sound trivial, but profiles suggest it's a significant factor in wartcl being 4x faster than partcl across the board. In part, I suspect a lot of C programs do a lot of redundant strlen-computation unintentionally.
#rustlang