A Quick Comparison of Nim vs. Rust
arthurtw.github.io
A Quick Comparison of Nim vs. Rust
1–10 of 94 posts
Re: A Quick Comparison of Nim vs. Rust
#2> It’s mysterious that Rust’s release version with -i ran slightly faster, though.
That's actually not surprising: a large fraction of time is spent in the map lookup, which in Rust is implemented as a B-tree, thus lookup time is (mildly) dependent on the map size. If keys are lowercased before inserting them, the map ends up having fewer elements.
The Nim version uses instead hash tables, whose lookup time is near-constant (that is, excluding memory hierarchy effects).
Re: A Quick Comparison of Nim vs. Rust
#3I'd guess that pulling that try-catch out of the loop would make things go much faster. Nim doesn't use 0-overhead exceptions, so setjmp needs to be called each time the try-catch is entered.
You should also use the re module, PEGs is not nearly as optimized as PCRE.
Re: A Quick Comparison of Nim vs. Rust
#4Are you just using --opt:speed to compile the Nim examples? For maximum performance you should be using -d:release.
Re: A Quick Comparison of Nim vs. Rust
#5Are you just using --opt:speed to compile the Nim examples? For maximum performance you should be using -d:release.
-d:release disables bounds checking, so the Rust examples would have to be modified for unchecked indexing for a fair comparison.
Re: A Quick Comparison of Nim vs. Rust
#6Are you just using --opt:speed to compile the Nim examples? For maximum performance you should be using -d:release.
-d:release disables bounds checking, so the Rust examples would have to be modified for unchecked indexing for a fair comparison.
It disables a lot of other things too. The current comparison is unfair. Why do the examples need to be modified to disable bounds checking for Rust? If it's easier you can compile the Nim examples with -d:release and enable bounds checking by also supplying --boundChecks:on.
Re: A Quick Comparison of Nim vs. Rust
#7I'm starting to really wish there was a GC-free (or at least) GC optional version of Nim. Nim with Rust's memory semantics would just be the best of everything.
Re: A Quick Comparison of Nim vs. Rust
#8I'm starting to really wish there was a GC-free (or at least) GC optional version of Nim. Nim with Rust's memory semantics would just be the best of everything.
Well, that's kinda the point. If there was a better way to have to achieve GC-free semantics, Rust would have taken it.
As for optional GC, didn't D haven't something along those lines?
Re: A Quick Comparison of Nim vs. Rust
#9Are you just using --opt:speed to compile the Nim examples? For maximum performance you should be using -d:release.
Oh, my bad. The numbers differ a lot (2~2.5x faster). I’ve updated the article.
Re: A Quick Comparison of Nim vs. Rust
#10Earlier quoted context omitted.
-d:release disables bounds checking, so the Rust examples would have to be modified for unchecked indexing for a fair comparison.
It disables a lot of other things too. The current comparison is unfair. Why do the examples need to be modified to disable bounds checking for Rust? If it's easier you can compile the Nim examples with -d:release and enable bounds checking by also supplying --boundChecks:on.
I’ve added additional results with Nim’s --boundChecks:on flag. Thank you two for the suggestions.