From 198bbd9c5dd2d11b40739084934779ef9506e963 Mon Sep 17 00:00:00 2001 From: hitzhangjie Date: Sat, 29 Jul 2023 01:31:21 +0800 Subject: [PATCH] docs/readme_zh: improve some translations --- README.zh_CN.md | 42 +++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/README.zh_CN.md b/README.zh_CN.md index 8c9f037..96f0449 100644 --- a/README.zh_CN.md +++ b/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(完全公平调度器)无感知。 ## 🌎 外部资源