4 ms·
One possible implementation of a hash table in Rust possibly beat another possible implementation of a hash table in C? This has little bearing on the overall
by charles-salvia 10y ago
One possible implementation of a hash table in Rust possibly beat another possible implementation of a hash table in C? This has little bearing on the overall inherent speed of either language. Conceptually, both languages should tend to perform similarly, as both are systems programming languages that allocate local variables on the stack and have no runtime overhead of a garbage collector. In practice, many real-world programs written in Rust (or C++) may in fact be faster than C equivalents, due to the possibility of inlining type-generic code (via templates in C++, and traits in Rust), whereas in C, generic code is usually implemented with the runtime overhead of void* pointers or function pointers.
- sanxiyn 10y agoIn the area of string formatting, templated C++ library should outperform C printf in theory, but this has been difficult to achieve in practice. So I understand why many people are skeptical about your "in practice" claim.
- charles-salvia 10y agoWith iostream, yeah - but in general C++ templates give the compiler more opportunity to outperform similar generic C code that relies on void pointers/function pointers. See the classic qsort vs. std::sort archetypal example of this. Also, with printf in particular, modern C compilers will generally parse the format flags at compile time if possible.
- paulddraper 10y agoOn the other hand, Rust's borrow checker eliminates very many correct programs (unless using unsafe code...not sure if that counts or not). At a macro scale, I have no doubts that Rust's benefits will win out. Understandable abstractions, fearless concurrency, etc. At a micro level, I would be surprised if some ugly, reprehensible C wasn't faster. I think Rust's approach to systems programming is superior in many ways. I just won't be surprised if it loses a microbenchmark.
- codys 10y ago> eliminates very many correct programs While this is also true (there are certainly correct programs that aren't writable in rust without unsafe{}), in this context I'm guessing you mean "incorrect programs".
- paulddraper 10y agoI mean correct, as in "Rust compile-time checks prohibit creating some compiled programs that would correctly produce the desired result". Rice's theorem means that rustc must fail programs that actually don't have memory errors. The same is true of C; some ASM programs can't be transcribed in a way that pleases a C compiler.
- red75prime 10y agoBut it doesn't mean that rustc (or C) will fail to compile all programs, which implement given functionality.
- red75prime 10y agoI don't know what downvoters were thinking. So I'll take a blind shot at explaining. I didn't say that Rice's theorem wasn't true. I said that in this case it doesn't matter. If program fails to compile, you don't give up because of Rice's theorem, you modify program to make it compile. Will it make program less efficient? Who knows. There's no theorem about that. Most likely it will.
- adrianN 10y agoI theory, Rust's type system can provide hints to the optimizer, for example about pointer aliasing. This is currently not leveraged (LLVM isn't too good at this, and rustc internal optimizations on the intermediate language are still on the roadmap).
- eutectic 10y ago
- attractivechaos 10y ago> in C, generic code is usually implemented with the runtime overhead of void pointers or function pointers.* When performance really matters, seasoned C programmers more often write task-specific implementations or choose macro-based libraries. In this particular benchmark, the C implementation is using a macro-based hash table which does not have the penalty of void*.