diff --git a/src/SUMMARY.md b/src/SUMMARY.md index de525321..bdd3f18a 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -133,8 +133,6 @@ - [基本用法](networking/async/tokio/basic.md) - [异步消息流](networking/async/tokio/stream.md) -- [常见陷阱 todo](traps/intro.md) - - [代码规范 doing](style-guide/intro.md) - [命名规范](style-guide/naming.md) - [代码风格(todo)](style-guide/code.md) @@ -162,6 +160,7 @@ - [过程宏(todo)](macro/procedure-macro.md) - [性能调优 todo](performance/intro.md) + - [深入理解move](performance/deep-into-move.md) - [糟糕的提前优化](performance/early-optimise.md) - [Clone和Copy](performance/clone-copy.md) - [Benchmark性能测试(todo)](performance/benchmark.md) diff --git a/src/performance/deep-into-move.md b/src/performance/deep-into-move.md new file mode 100644 index 00000000..330dc571 --- /dev/null +++ b/src/performance/deep-into-move.md @@ -0,0 +1,212 @@ +# 所有权转移时发生了奇怪的深拷贝 + +在所有权章节中，我们详细介绍过[所有权转移(move)](https://course.rs/basic/ownership/ownership.html#转移所有权), 里面提到过一个重点：当类型实现`Copy`特征时，不会转移所有权，而是直接对值进行拷贝： +```rust +fn main() { + let x = 1; + let y = x; + // 不会报错 + println!("我(x)的值仅仅是被复制了，我还拥有值的所有权，不信你看：{:?}",x); + + let s = "aaa".to_string(); + let s1 = s; + // 会报错 + println!("我(s)的值被转移给了s1，我已经失去所有权了: {}",s); +} +``` + +这里的`x`是数值类型，因此实现了`Copy`特征，当赋值给`y`时，仅仅是复制了值，并没有把所有权转移给`y`，但是`s`恰好相反，它没有实现`Copy`特征，当赋值后，所有权被转移给`s1`，最终导致了最后一行代码的报错. + +根据之前的所有权学习章节，所有权转移时的仅仅是复制一个引用，并不会复制底层的数据，例如上面代码中，`s`的所有权转移给`s1`时，仅仅是复制了一个引用，该引用继续指向之前的字符串底层数据，因此**所有权转移的性能是非常高的**。 + +但是如果一切都这么完美，也不会出现这篇文章了，实际上是怎么样？先来看一段代码. + +## move时发生了数据的深拷贝 +```rust +struct LargeArray { + a: [i128; 10000], +} + +impl LargeArray { + #[inline(always)] + fn transfer(mut self) -> Self { + println!("{:?}", &mut self.a[1] as *mut i128); + + // 改变数组中的值 + self.a[1] += 23; + self.a[4] += 24; + + // 返回所有权 + self + } +} + +fn main() { + let mut f = LargeArray { a: [10i128; 10000] }; + + println!("{:?}", &mut f.a[1] as *mut i128); + + let mut f2 = f.transfer(); + + println!("{:?}", &mut f2.a[1] as *mut i128); +} +``` + +上面的例子很简单，创建了一个结构体`f`(内部有一个大数组)，接着将它的所有权转移给`transfer`方法，最后再通过`Self`返回，转移给`f2`，在此过程中，观察结构体中的数组第二个元素的内存地址如何变化。 + +这里还有几个注意点： +- `LargeArray`没有实现`Copy`特征，因此在所有权转移时， **本应该**只是复制一下引用，底层的数组并不会被复制 +- `transfer`方法的参数`self`表示接收所有权，而不是借用，返回类型`Self`也表示返回所有权，而不是返回借用, 具体内容在[方法](https://course.rs/basic/method.html)章节有介绍 + +从上可知，我们并不应该去复制底层的数组，那么底层数组的地址也不应该变化，换而言之三次内存地址输出应该是同一个地址。但是真的如此吗？世事难料： +```console +0x16f9d6870 +0x16fa4bbc0 +0x16fa24ac0 +``` + +果然，结果让人大跌眼镜，竟然三次地址都不一样，意味着每次转移所有权都发生了底层数组的深拷贝！什么情况？！！如果这样，我们以后还能信任Rust吗？完全不符合官方的宣传。 + +在福建有一个武夷山5A景区，不仅美食特别好吃，而且风景非常优美，其中最著名的就是历时1个多小时的九曲十八弯漂流，而我们的结论是否也能像漂游一样来个大转折？大家拭目以待。 + + +## 罪魁祸首println? +首先，通过谷歌搜索，我发现了一些蛛丝马迹，有文章提到如果通过`println`输出内存地址，可能会导致编译器优化失效，也就是从本该有的所有权转移变成了深拷贝，不妨来试试。 + +但是问题又来了，如果不用`println`或者类似的方法，我们怎么观察内存地址？好像陷入了绝路。。。只能从Rust之外去想办法了，此时大学学过的汇编发挥了作用： +```asm +.LCPI0_0: + .quad 10 + .quad 0 +example::xxx: + mov eax, 160000 + call __rust_probestack + sub rsp, rax + mov rax, rsp + lea rcx, [rsp + 160000] + vbroadcasti128 ymm0, xmmword ptr [rip + .LCPI0_0] +.LBB0_1: + vmovdqu ymmword ptr [rax], ymm0 + vmovdqu ymmword ptr [rax + 32], ymm0 + vmovdqu ymmword ptr [rax + 64], ymm0 + vmovdqu ymmword ptr [rax + 96], ymm0 + vmovdqu ymmword ptr [rax + 128], ymm0 + vmovdqu ymmword ptr [rax + 160], ymm0 + vmovdqu ymmword ptr [rax + 192], ymm0 + vmovdqu ymmword ptr [rax + 224], ymm0 + vmovdqu ymmword ptr [rax + 256], ymm0 + vmovdqu ymmword ptr [rax + 288], ymm0 + vmovdqu ymmword ptr [rax + 320], ymm0 + vmovdqu ymmword ptr [rax + 352], ymm0 + vmovdqu ymmword ptr [rax + 384], ymm0 + vmovdqu ymmword ptr [rax + 416], ymm0 + vmovdqu ymmword ptr [rax + 448], ymm0 + vmovdqu ymmword ptr [rax + 480], ymm0 + vmovdqu ymmword ptr [rax + 512], ymm0 + vmovdqu ymmword ptr [rax + 544], ymm0 + vmovdqu ymmword ptr [rax + 576], ymm0 + vmovdqu ymmword ptr [rax + 608], ymm0 + add rax, 640 + cmp rax, rcx + jne .LBB0_1 + mov rax, qword ptr [rsp + 16] + mov rdx, qword ptr [rsp + 24] + add rax, 69 + adc rdx, 0 + add rsp, 160000 + vzeroupper + ret +``` + +去掉所有`println`后的汇编生成如上所示(大家可以在godbolt上自己尝试)，以我蹩脚的汇编水平来看，貌似没有任何数组拷贝的发生，也就是说： +如同量子的不可观测性，我们的`move`也这么傲娇？我们用println观测，它就傲娇去复制，不观测时，就老老实实转移所有权？WTF! + +事情感觉进入了僵局，下一步该如何办？ + +## 栈和堆的不同move行为 +我突然灵光一现，想到一个问题，之前的所有权转移其实可以分为两类：**栈上数据的复制和堆上数据的转移**，这也是非常符合直觉的，例如`i32`这种类型实现了`Copy`特征，可以存储在栈上，因此它就是复制行为，而`String`类型是引用存储在栈上，底层数据存储在堆上，因此转移所有权时只需要复制一下引用即可。 + +那问题来了，我们的`LargeArray`存在哪里？这也许就是一个破局点！ +```rust +struct LargeArray { + a: [i128; 10000], +} +``` +结构体是一个复合类型，它内部字段的数据存在哪里，就大致决定了它存在哪里。而该结构体里面的`a`字段是一个数组，而不是动态数组`Vec`，从[数组](https://course.rs/basic/compound-type/array.html#创建数组)章节可知：数组是存储在栈上的数据结构！ + +再想想，栈上的数据在`move`的时候，是要从一个栈复制到另外一个栈的，那是不是内存地址就变了？！因此，就能完美解释，为什么使用`println`时，数组的地址会变化了，是因为栈上的数组发生了复制。 + +但是问题还有，为什么不使用`println`，数组地址就不变？要解释清楚这个问题，先从编译器优化讲起。 + +## 编译器对move的优化 +从根本上来说，`move`就意味着拷贝复制，只不过看是浅拷贝还是深拷贝，对于堆上的数据来说，浅拷贝只复制引用，而栈上的数据则是整个复制。 + +但是在实际场景中，由于编译器的复杂实现，它能优化的场景远比我们想象中更多，例如对于`move`过程中的复制，编译器有可能帮你优化掉，在没有`println`的代码中，该`move`过程就被Rust编译器优化了。 + +但是这种编译器优化非常复杂，而且随着Rust的版本更新在不停变化，因此几乎没有人能说清楚这里面的门门道道，但是有一点可以知道：**`move`确实存在被优化的可能性，最终避免了复制的发生**. + +那么`println`没有被优化的原因也呼之欲出了: 它阻止了编译器对`move`的优化。 + +## println阻止了优化 +编译器优化的一个基本准则就是：中间过程没有其它代码在使用，则可以尝试消除这些中间过程。 + +回头来看看`println`: +```rust +println!("{:?}", &mut f.a[1] as *mut i128); +``` + +它需要打印数组在各个点的内存地址，假如编译器优化了复制，那这些中间状态的内存地址是不是就丢失了？对于这种可能会导致状态丢失的情况，编译器是不可能进行优化的，因此`move`时的栈上数组复制就顺理成章的发生了, 还是2次。 + + +## 最佳实践 +那么，在实践中遇到这种情况怎么办？ + +#### &mut self +其实办法也很多，首当其冲的就是使用`&mut self`进行可变借用，而不是转移进来所有权，再转移出去。 + + +#### Box分配到堆上 +如果你确实需要依赖所有权的转移来实现某个功能(例如链式方法调用:`x.a().b()...`)，那么就需要使用`Box`把该数组分配在堆上，而不是栈上： +```rust +struct LargeArray { + a: Box<[i128; 10000]>, +} + +impl LargeArray { + #[inline(always)] + fn transfer(mut self) -> Self { + println!("{:?}", &mut self.a[1] as *mut i128); + + //do some stuff to alter it + self.a[1] += 23; + self.a[4] += 24; + + //return the same object + self + } +} + +fn main() { + let mut f = LargeArray { a: Box::new([10i128; 10000] )}; + + println!("{:?}", &mut f.a[1] as *mut i128); + + let mut f2 = f.transfer(); + + println!("{:?}", &mut f2.a[1] as *mut i128); +} +``` + +输出如下: +``` +0x138008010 +0x138008010 +0x138008010 +``` + +完美符合了我们对堆上数据的预期，hooray! + +#### 神龟莫测的编译器优化 +当然，你也可以选择相信编译器的优化，虽然很难识它真面目，同时它的行为也神鬼莫测，但是总归是在之前的例子中证明了，它确实可以，不是嘛？ = , = + + diff --git a/src/traps/intro.md b/src/traps/intro.md deleted file mode 100644 index 3e9811cb..00000000 --- a/src/traps/intro.md +++ /dev/null @@ -1,3 +0,0 @@ -# 常见陷阱 todo - -本章收集各种Rust使用中常见的陷阱，帮助大家提前规避或者在遇到时能够迅速解决。 \ No newline at end of file diff --git a/writing-material/books.md b/writing-material/books.md index 40cbcbe1..54c424bd 100644 --- a/writing-material/books.md +++ b/writing-material/books.md @@ -1,6 +1,6 @@ ## 本书参考的书籍 -1. [Rust语言](https://rustwiki.org/zh-CN/book/) +1. [Rust语言](https://doc.rust-lang.org/book) 3. [Cargo教学](https://doc.rust-lang.org/cargo/index.html) @@ -13,11 +13,12 @@ 7. [Rust in action](https://livebook.manning.com/book/rust-in-action/chapter-5/) - [示例](https://github.com/barabadzhi/rust-in-action) -8. [Rust高级编程](https://learnku.com/docs/nomicon/2018/310-phantom-data/4721?show_current_version=yes) - [Rust nomicon](https://doc.rust-lang.org/nomicon/dot-operator.html) +8. [Rust nomicon](https://doc.rust-lang.org/nomicon/dot-operator.html) 9. [Rust Primer](https://rustcc.gitbooks.io/rustprimer/content/1st-glance/) 10. [Rust Forge](https://forge.rust-lang.org/infra/other-installation-methods.html#other-rust-installation-methods) -11. [rustc开发者之书](https://rustc-dev-guide.rust-lang.org/method-lookup.html) \ No newline at end of file +11. [rustc开发者之书](https://rustc-dev-guide.rust-lang.org/method-lookup.html) + +12. [Rust Style](https://doc.rust-lang.org/1.6.0/style/README.html) \ No newline at end of file