Merge pull request #34 from hitzhangjie/docs/improve_readme

docs/readme_zh: improve some translations

README.zh_CN.md

@@ -150,15 +150,15 @@ Teiva Harsanyi是Google的高级软件工程师。他在多个领域工作过，
       - [不使用模糊测试 (社区反馈错误)](#不使用模糊测试-社区反馈错误)
     - [优化技术](#优化技术)
       - [不理解CPU cache (#91)](#不理解cpu-cache-91)
-      - [写了并发代码，会导致false sharing (#92)](#写了并发代码会导致false-sharing-92)
-      - [不有考虑指令级的并行 (#93)](#不有考虑指令级的并行-93)
+      - [写的并发处理逻辑会导致false sharing (#92)](#写的并发处理逻辑会导致false-sharing-92)
+      - [没有考虑指令级的并行 (#93)](#没有考虑指令级的并行-93)
       - [不了解数据对齐 (#94)](#不了解数据对齐-94)
       - [不了解 stack vs. heap (#95)](#不了解-stack-vs-heap-95)
-      - [不知道如何减少内存分配次数 (API 变化, compiler optimizations, and `sync.Pool`) (#96)](#不知道如何减少内存分配次数-api-变化-compiler-optimizations-and-syncpool-96)
-      - [不依赖于内联 (#97)](#不依赖于内联-97)
+      - [不知道如何减少内存分配次数 (API调整, compiler optimizations, and `sync.Pool`) (#96)](#不知道如何减少内存分配次数-api调整-compiler-optimizations-and-syncpool-96)
+      - [不注意使用内联 (#97)](#不注意使用内联-97)
       - [不使用Go问题诊断工具 (#98)](#不使用go问题诊断工具-98)
       - [不理解GC是如何工作的 (#99)](#不理解gc是如何工作的-99)
-      - [不了解在Docker或者K8S中运行应用的性能影响 (#100)](#不了解在docker或者k8s中运行应用的性能影响-100)
+      - [不了解Docker或者K8S对运行的Go应用的性能影响 (#100)](#不了解docker或者k8s对运行的go应用的性能影响-100)
   - [🌎 外部资源](#-外部资源)
     - [英文资料](#英文资料)
     - [中文资料](#中文资料)
@@ -661,38 +661,39 @@ Go 的上下文（context）也是 Go 并发编程的基石之一。上下文允
 
   意识到 cache line 概念对于理解如何在数据密集型应用中组织数据非常关键。CPU 并不是一个一个字来获取内存。相反，它通常复制一个 64字节长度的 cache line。为了获得每个 cache line 的最大效用，需要实施空间局部性。
 
-* 系列structs元素构成的slice vs. 多个slices字段构成的struct
+* 一系列struct元素构成的slice vs. 多个slice字段构成的struct
 
 * 概率性的问题 
 
-  使得代码对CPU来说更加可预测可以成为高效优化某些函数的一种方式。比如,一个单位或常量的步长对CPU来说是可预测的，但是这些意外的用例是不可以预测的。
+  提高CPU执行代码时的可预测性，也是优化某些函数的一个有效方法。比如，固定步长或连续访问对CPU来说是可预测的，但非连续访问（例如链表）就是不可预测的。
 
-* cache更新策略
-* cache
+* cache放置策略
 
-  为了避免严重的性能问题，因此只利用了缓存的非常小的一部分，请注意缓存是分区的。
+  要注意现代缓存是分区的（set associative placement，组相连映射），要注意避免使用 `critical stride`，这种步长情况下只能利用 cache 的一小部分。
 
-#### 写了并发代码，会导致false sharing (#92)
+  > critical stride，这种类型的步长，指的是内存访问的步长刚好等于 cache 大小。这种情况下，只有少部分 cacheline 被利用。
 
-要知道CPU cache中的L1、L2等低级的cache不会在多个处理器核心见进行共享，这有助于避免性能下降的模式，例如false sharing。分享内存只是一个幻象。
+#### 写的并发处理逻辑会导致false sharing (#92)
 
-#### 不有考虑指令级的并行 (#93)
+了解 CPU 缓存的较低层的 L1、L2 cache 不会在所有核间共享，编写并发处理逻辑时能避免写出一些降低性能的问题，比如伪共享（false sharing）。内存共享只是一种假象。
 
-使用指令级并行（ILP）优化代码的特定部分，以允许CPU执行尽可能多的并行指令。识别数据障碍是主要步骤之一。
+#### 没有考虑指令级的并行 (#93)
+
+使用指令级并行（ILP）优化代码的特定部分，以允许CPU尽可能执行更多可以并行执行的指令。识别指令的数据依赖问题（data hazards）是主要步骤之一。
 
 #### 不了解数据对齐 (#94)
 
-记住Go中基本类型与其自身大小对齐，例如,按降序大小重新组织结构体的字段可以形成更紧凑的结构体（减少内存分配，更好的空间局部性），这有助于避免一些常见的错误。
+记住Go中基本类型与其自身大小对齐，例如，按降序从大到小重新组织结构体的字段可以形成更紧凑的结构体（减少内存分配，更好的空间局部性），这有助于避免一些常见的错误。
 
 #### 不了解 stack vs. heap (#95)
 
 了解堆和栈之间的区别是开发人员的核心知识点，特别是要去优化一个Go程序时。栈分配的开销几乎为零，而堆分配则较慢，并且依赖GC来清理内存。
 
-#### 不知道如何减少内存分配次数 (API 变化, compiler optimizations, and `sync.Pool`) (#96)
+#### 不知道如何减少内存分配次数 (API调整, compiler optimizations, and `sync.Pool`) (#96)
 
 减少内存分配次数也是优化Go应用的一个重要方面。这可以通过不同的方式来实现,比如仔细设计API来避免不必要的拷贝，以及使用 `sync.Pool` 来对待分配对象进行池化。
 
-#### 不依赖于内联 (#97)
+#### 不注意使用内联 (#97)
 
 使用快速路径的内联技术来更加有效地减少调用函数的摊销时间。
 
@@ -702,12 +703,11 @@ Go 的上下文（context）也是 Go 并发编程的基石之一。上下文允
 
 #### 不理解GC是如何工作的 (#99)
 
-理解如何调优GC能够引发很多收益，例如处理徒增的负载信息更有效率。
+理解如何调优GC能够带来很多收益，例如有助于更高效地处理突增的负载。
 
-#### 不了解在Docker或者K8S中运行应用的性能影响 (#100)
+#### 不了解Docker或者K8S对运行的Go应用的性能影响 (#100)
 
-To help avoid CPU throttling when deployed in Docker and Kubernetes, keep in mind that Go isn’t CFS-aware.
-为了避免CPU throttling问题，当我们部署应用在Docker和Kubernetes时，要记住Go语言不支持CFS(完全公平调度器)。
+为了避免CPU throttling（CPU限频）问题，当我们在Docker和Kubernetes部署应用时，要知道Go语言对CFS(完全公平调度器)无感知。
 
 ## 🌎 外部资源