Can anyone share tips for Optimize coding in Rust

Can any one share tips for Optimize coding in Rust for newbies in the world of system programming
like in c/c++ reduce number of local variables

and is it necessary to follow old faction optimize coding style in rust since it provide more security and safety

I can, see below. But since when has it been suggested to reduce the number of local variables in C/C++ to increase performance?

If they are not local variables on the stack then they are going to be on the heap, which I don't think can be faster as that requires a pointer dereference and will require allocation and decalocation.

Or they are globals, which is generally bad practice and probably does not gain much performance if any.

Historically the C/C++ world has been full of helpful advice, micro-optimizations, intended to increase performance. Most of it is obsolete and does not work in the modern world. Modern compilers can do a much better job of rearranging code for speed than most programmers can even if they are coding in assembler. Processors are full of optimization tricks like executing instructions in parallel, reordering operations, predicting branch directions and so on.

Optimization today is far more about ensuring the data you are working on is found in cache as much as possible. Which is a good reason to avoid OOP for performance critical code.

Security and safety is another matter. A you know Rust provides memory safety and freedom from race conditions between threads. That goes a long way to ensuring security but of course there are all kind of ways you can write insecure code even in a "safe" system. Security is not my expertise so I will leave it at that.

When it comes to Rust performance I have found that I can always match or even beat the speed of C for the same functionality using the same algorithm. A few things I picked up along the way:

  1. Rust does bounds checking on array indexing for memory safety. Often that can be checked at compile time, often it has to be checked at run time because of the way you have written your code. Be sure to help the compiler. By iterating over slices rather than writing C style "for" loops and indexing things can go much faster as the compiler creates the indices and so does not have to range check them on every iteration

  2. Use fast_floats: fast_floats - Rust Turns out that with that and 1) above the compiler can vectorize things nicely.

  3. Beware of those who offer "functional" style solutions to your performance problems. I have found they can often be verbose, obfuscated and not much faster if any. Sometimes the functional style in Rust is just not the way to get performance. But when it is things can really sing!

  4. Beware of those who suggest use of "unsafe" for performance. I like to avoid using "unsafe" in my application code. I has turned out that "unsafe" has never been required to match the speed of C in the problems I have tackled.

You might like to look at, at run, a couple of my experiments where I have all kind of Rust solutions trying to match C speed for some function, suggested by forum members. It's interesting to see what gets performance and what does not:

loop_blocking: GitHub - ZiCog/loop_blocking: Experiments in achieving C performance in Rust when manipulating arrays.
insane-british-anagram-rust: GitHub - ZiCog/insane-british-anagram-rust: Rust program to find anagrams in the Debian british-english-insane dictionary file.
rust_convolution: GitHub - ZiCog/rust_convolution

2 Likes

General advice to all nauplii (new Rustaceans):
unsafe is a very sharp knife with limited utility. Do not use it until you have a lot of experience in Rust. Even using unsafe for FFI is hazardous. Using it elsewhere is seldom warranted until after a safe version of the code is already debugged and working. See this recent discussion of where use of unsafe may be warranted, and where it is not.

3 Likes

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.