This book is not about creating processors, so you might think that all this branch prediction theory does not make sense for our use case of improving the efficiency of our Rust code. But the reality is that this theory can make us develop more efficient applications.

First, knowing that patterns in conditional execution will probably be detected after two passes by new and expensive processors will make us try to use those patterns if we know that our code will be mainly used by newer processors. On the other hand, if we know that our code will run in a cheaper or older processor, we might optimize its execution by maybe writing the result of the pattern condition sequentially if possible (in a loop) or by trying to group conditions in other ways.

Also, we have to take into account compiler optimizations. Rust will often optimize loops to the point of copying some code 12 times if it knows it will always be executed that number of times, to avoid branching. It will also lose some optimization prediction if we have many branches in the same code generation unit (a function, for example).

This is where Clippy lints such as cyclomatic complexity enter into play. They will show as functions where we are adding too many branches. This can be fixed by dividing such functions into smaller ones. The Rust compiler will better optimize the given function, and if we have link-time optimizations enabled, it might even end up in the same function, in the end, making the processor branchless.

We shouldn't completely rely on hardware branch prediction, especially if our code is performance-critical, and we should develop taking into account how the processor will optimize it too. If we know for sure which processor will be running our code, we might even decide to learn the branch prediction techniques of the processor from the developer manual and write our code accordingly.