The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

TS McNamara (45) [Avatar] Offline
#1
The team at Manning informs me that the Rust in Action MEAP will be updated shortly.

What does chapter 6 cover? Here is an excerpt from the introduction:

This chapter covers

• What a pointer is and why some of them are “smart”
• What the terms “the stack” and “the heap” mean
• How a program views its memory and why that’s a lie

The chapter provides you with some of the tacit knowledge held by systems programmers about how the computer’s memory operates. It aims to be the most accessible guide to pointers and memory management available. You will be learning about how applications interact with an operating system. Programmers who understand these dynamics can use that knowledge to maximize their programs' performance, while minimizing their memory footprint.


For this chapter, I'm actively soliciting suggestions for improving the text. It's been several weeks' work so far and I feel that I am too close to be objective. Please let me know what you think!
19705 (3) [Avatar] Offline
#2
Hi,

I have just made it through to the end of chapter 6 now and I have to say it is an amazing book so far! It goes a lot deeper into lower level areas than the other Rust books which really helps. Thankyou so much for writing it.

On page 168 you say it can be costly to reach the capacity of the TLB (typically around 100). Do you mean 100 bytes? Is this the value that is returned by std::mem::size_of<>()?

Are there any idiomatic tricks in Rust that you can use to keep your data structures smaller, or is it purely down to the design of the code? Time and space allowing, I would love to see some examples here. A program with an inefficiently sized data structure that runs slowly, then refactored so that it fits in the TLB and runs demonstrably faster - although I do appreciate that could be a whole chapter (maybe even book) in itself. My appetite has definitely been whetted!

Looking forward to the next chapters!
TS McNamara (45) [Avatar] Offline
#3
19705 wrote:Hi,

I have just made it through to the end of chapter 6 now and I have to say it is an amazing book so far! It goes a lot deeper into lower level areas than the other Rust books which really helps. Thankyou so much for writing it.


And thank you for this feedback! It's really heartening. Writing a technical book is as hard as everyone says it is! And because the other Rust books are of such high quality themselves, it makes the threshold even higher.

On page 168 you say it can be costly to reach the capacity of the TLB (typically around 100). Do you mean 100 bytes? Is this the value that is returned by std::mem::size_of<>()?


This is a good question. No, it relates to the CPU's word size (isize and usize). Intel CPUs have 128 slots in the TLB, half for data and half for code. And it gets even more complicated than that as the TLB is split into L1 and L2 cache itself. There's lots of complexity there, which meant that the chapter took a lot more time than I had originally budgeted. I hope that the balance has been struck.

Are there any idiomatic tricks in Rust that you can use to keep your data structures smaller, or is it purely down to the design of the code? Time and space allowing, I would love to see some examples here. A program with an inefficiently sized data structure that runs slowly, then refactored so that it fits in the TLB and runs demonstrably faster - although I do appreciate that could be a whole chapter (maybe even book) in itself. My appetite has definitely been whetted!


Difficult question.

I think that a good rule of thumb is that if you can keep to types that implement Copy, your program should run very fast. This implies numeric types such as integers and floating point values.

Deeply nested structures with lots of pointers will lead to cache thrashing. But it's not that simple. As part of the development of the chapter, I experimented with several programs to see if I could make things deliberately slow. But the compiler was always too smart and much of my deliberately inefficient code was optimized away.


Looking forward to the next chapters!


They shouldn't be too far away. There are about 80 pages awaiting release that just need an extra few tweaks before they get released smilie

If you would like to take a sneak peek, you are welcome to check out the NTP client that I have written that will be explained in chapter 9 or so: https://git.nzoss.org.nz/tim-mcnamara/timepong

Thanks again for the words of encouragement. They're very helpful.
504184 (1) [Avatar] Offline
#4
A “raw” pointer is a pointer is there a.


Is the above (first) sentence in 6.1.1 (Raw pointers in Rust) is misconstrued?

Also here some typos: https://livebook.manning.com#!/book/rust-in-action/chapter-6/v-7/point-3284-47-47-0. Should it be (changes are in red)?:

  • They do not own their values. The Rust compiler does not check that the referent data is still valid when they’re accessed.

  • Multiple raw pointers to the same data is allowsed. Every raw pointer can have write read/write access to that data. This means that there is no time when Rust can guarantee that the shared data is valid.


  • P.S. Should we report typos as well or the book will be proofread anyway?
    Elesha H. (5) [Avatar] Offline
    #5
    The book will be proofread, so reporting obvious typos isn't necessary. If you see a mistake that would not be obvious to a non-developer who was proofreading, we would appreciate your reporting that. Thank you! :o)
    453123 (8) [Avatar] Offline
    #6
    in Figure 6.1, the graphic has the following statement:

    Programming languages that use raw pointers must use a convention to deduce the stopping condition. The convention in C and its descendants is is to terminate when 0 is detected

    Shouldn't this be qualified? Isn't this only the strategy for c strings as opposed to a general strategy for pointers? An array of ints on the heap doesn't terminate with \0.
    453123 (8) [Avatar] Offline
    #7
    In the section on profiling the particle sym, the instructions given for generating tracing data only work for linux. timeout doesnt exist on os x, nor does ltrace (that would be gtimeout and dtrace). I would imagine that windows is the same story. It would be great if the chapter would also cover os x and windows.
    453123 (8) [Avatar] Offline
    #8
    Just got to example 6.24.

    It is quite unfortunate IMHO that this and the next example are windows-specific. I would wager that far more people buying this book are using linux or os x. Please add corresponding code for Linux at least.