I propose to add a book about optimizing Rust code to the bookshelf.
I was recently adding a comment to an issue that asks for more documentation about LTO, ThinLTO and Co.. The issue raised the question where this kind of documentation needs to go. While thinking about it, I realized there is no appropriate place in the bookshelf:
- “The Rust Programming Language”: wrong experience level (beginner instead of intermediate)
- “The Cargo Book”: wrong topic
- “The Unstable Book”: wrong topic
- “The Rustonomicon”: the closest we can get, but also wrong topic
- “The Reference”: wrong topic
- “The Rustdoc Book” wrong topic, again
LTO, ThinLTO and Co. are clearly about optimizing Rust code. Therefore, such a book would be nice to have.
When thinking about optimization and performance, more topics come into my mind:
- Multithreading, including Rayon and Futures
- SIMD, including faster and the work currently done in the compiler and the standard library
- Zero cost abstractions in general: How do they compile down to super-fast bytecode? What to do? What to avoid?
- Compiler optimizations in general: What can/can’t the compiler optimize?
- How to benchmark? What tools are available?
A book about optimization and performance would be documentation at intermediate level. This is exactly what the 2018 Roadmap asks for!
Details design, drawbacks, etc.
To be done… I would like to hear feedback first!
Edit: A good name for a book on optimizing Rust might be “Thrust”…
Sounds like a very nice project! I would definitely be game for giving an occasional hand in writing or reviewing this.
You may want to add (or link to) more general optimization material, such as a hardware architecture primer, or a guide to profiling with tools such as Linux perf, WPA, or Xcode Instruments.
Another topic which you could feature is IO optimizations (e.g. async network IO with tokio/futures, disk I/O considerations) and work distribution across a network (e.g. timely dataflow). These are areas in which Rust is less mature, but which people will be investigating when studying Rust performance tricks.
Considering the title, since “Thrust” is already taken by an NVidia project, you may prefer a variation on this theme such as “Thrusting Rust” .
This sounds like a good idea, although it should probably start life outside of the core Rust organisation first. @teiesti, what would be the scope of such a book? Would you also be covering things like general profiling techniques, algorithms, commonly used performant functions (e.g.
memchr for string searching), and micro-optimisations?
I’d also want to go into how to write zero-copy code (e.g. efficiently parsing a binary protocol), and knowing when you should reach for unsafe if you need extra speed (unchecked indexing comes to mind here). It could be written as a series of extended examples where you start off with a problem and the initial naive solution, then you incrementally make it faster.
Just throwing around title ideas, what about “Rust - Putting the fast in fast, safe, and concurrent”?
@teiesti, what would be the scope of such a book?
I think that should be a community decision. For the moment, I would like to collect ideas. Later I would start the RFC process to fix the table of contents, the name and other similar thing. When the RFC is finally merged, we could start writing.
Some words about the time horizon: This weekend I’ll have almost no internet. Next week I’ll try to write a RFC draft.
Unfortunately, I have to inform You that I will not pursue this project any further. At least not for the moment.
- I believe this project is a lot of work that needs many helping hands.
- From the frequency of comments in this threat I deduce that less people are interested than I initially thought.
Please don’t get me wrong: I really appreciate the positive feedback You gave. I still like the idea to write such a book. I am very grateful to all who offered their help. But I think it is just not enough to make it in the end.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.