- 博客(452)
- 资源 (32)
- 收藏
- 关注
RSS订阅
原创 UML顺序图规范
1 生命线一般为虚线2 消息(1)创始消息实心圆开头，实心箭头(2)同步消息实心箭头3 控制期表示阻塞调用4 返回值5 自身消息6 创建实例虚线实心箭头，新创建的对象实例画在创建时的高度上7 销毁对象用<<destroy>>和X表示对象的销毁8 图框常见的图框操作符：alt：选择性的片段，用于表示保护信息表达的互斥逻辑。loop：用于表示保护信息为真的循环片段。loop(n)指明循环的次数。opt：当保护信息为...
2021-10-31 13:28:13
1464
原创 [Android P]OpenCamera详细分析(Camera2+Hal3)
因为工作涉及到Android Camera系统的问题，本文就整理了在Android P上讲解OpenCamera比较详细的文章，结合Andriod P源码，以架构图、UML顺序图、UML类图和关键代码走读的方式，从App层、Framework层、Hal层详细分析了OpenCamera的流程。如有分析的不对的地方，欢迎大家指正~注意：Camera系统架构采用Camera2+Hal3。参考博客：Android Camera2+HAL3架构_既不是天才，便做那疯子！-CSDN博客[A
2021-10-23 23:00:21
8762
4
原创 gdb如何从堆栈破坏的堆栈中定位问题(ucontext_t)
对于大多数堆栈破坏的情况没有有效方法，只能缩小问题代码范围，不断测试复现，找出容易复现的方式，一步步解决。但是有一种情况，如果你的堆栈破坏了，但是有ucontext_t进程上下文信息，那么是可以继续分析的!本文介绍了堆栈破坏但有ucontext_t进程上下文信息的前提下用gdb调试定位问题的过程。(1)使用带有debug信息的动态库(SDL,X11)todoCSDN文章链接(2)查看log的Stack traceSegmentation fault(Invalid ...
2021-04-05 12:21:52
2959
原创 3 vim-config软件包
vim是linux系统中的编辑工具，配置好vim可以大大提高我们的工作效率。在使用vim时我们常常需要自己配置vimrc，安装需要的插件等。这一系列的配置比较繁琐，很多人望而生畏，于是渐渐放弃vim。最近看到一个博主关于[vi/vim使用进阶]的博客，学习后用起来非常方便。但弊端是配置的插件繁多，快捷键繁多，不易记忆，一旦更换电脑环境需要重新配置。为此，我将[vi/vim使用进阶]中的vim配置做成了软件包(vim-config)托管在Github上，到了不同环境，只需要./install.sh便可一键配置
2020-12-20 18:14:24
1393
4
原创 高通QFIL刷机:高通sdm845_la2.0用QFIL软件meta_build和flat_build刷机
[1 代码准备](i)amss_standard_oem:高通源码(ii)test_device:amss_standard_oem对应的二进制文件(高通已经编译)(iii)caf:高通源码对应的谷歌源码[2 编译源码]将amss_standard_oem/LINUX/android/vendor/qcom目录下的proprietary文件夹拷贝到caf/vendor...
2018-10-25 20:23:27
21841
13
原创 OpenCamera流程详细分析(Camera1+Hal1)
以本文记录下学习sdm660 camera模块的总结：首先特别感谢https://blog.csdn.net/armwind博主的文章（一）目录一. android camera系统架构图二. opencamera(1)Bn Bp对象的理解(2)回调函数的注册，监听(3)aidl—ICameraService,hidl--ICameraDevice三. takepic...
2018-10-15 11:19:26
4616
1
翻译 13 Case Study
这一章是一个系统性能案例研究：讲述了一个真实世界性能问题的故事，从最初的报告到最终解决。这个特定的问题发生在一个生产环境的云计算环境中；我选择它作为系统性能分析的一个常规示例。我在本章的目的不是引入新的技术内容，而是利用叙事来展示工具和方法如何在实践中应用，即在真实的工作环境中。这对于那些尚未处理过真实系统性能问题的初学者应该特别有用，它提供了一个跟踪专家如何处理这些问题的视角，评论了在分析过程中专家可能会考虑的事情，以及为什么会这样。这并不一定是记录最佳可能的方法，而是为什么采取了某种方法。所有姓名已
2024-06-22 16:55:31
17
翻译 12 Benchmarking
基准测试以受控方式测试性能，使得可以比较选择并理解性能限制——在其在生产环境中遇到之前。这些限制可能是系统资源、虚拟化环境（云计算）中的软件限制，或者目标应用程序中的限制。之前的章节已经探讨了这些组件，描述了存在的限制类型以及用于分析它们的工具。之前的章节还介绍了微基准测试的工具，这些工具使用简单的人工工作负载来研究限制。其他类型的基准测试包括客户工作负载模拟，试图复制客户使用模式，以及追踪重放。无论你使用哪种类型，都很重要分析基准测试，以便确认正在测量什么。基准测试只告诉你系统可以多快地运行基准测试；你
2024-06-22 16:50:16
17
翻译 11 Cloud Computing
云计算的兴起解决了性能领域中的一些问题，同时也带来了其他问题。云通常建立在虚拟化技术之上，允许多个操作系统实例或租户共享一个物理服务器。这意味着可能存在资源争用：不仅来自其他进程，这在Unix中是常见的，而且还来自其他整个操作系统。隔离每个租户的性能影响至关重要，同样重要的是识别由其他租户引起的性能不佳。本章讨论了云计算环境的性能，并分为三个部分：背景介绍了一般云计算架构及其性能影响。操作系统虚拟化是指由单个内核管理系统，创建相互隔离的虚拟操作系统实例。本节以SmartOS Zones为例进行了实现。
2024-06-22 16:42:19
13
翻译 10 Network
不幸的是，这些组件上的大型缓冲区的使用可能会导致一个称为缓冲膨胀的问题，其中数据包被排队等待了很长时间。在这种情况下，当临时端口仍然与处于TIME-WAIT状态的先前TCP会话关联时发送了SYN包，如果新的SYN包被误识别为旧连接的一部分（发生冲突），则可能会被拒绝。幸运的是，其中许多具有长的描述性名称，因此它们的含义可能很明显。当按下 Ctrl-C 键时，将打印一个摘要，显示缓存的进程 ID（cpid）、套接字积压的当前最大长度（max_q），以及一个分布图，显示在添加新连接时测量的积压长度。
2024-06-22 14:00:00
18
翻译 9 Disks
磁盘I/O可能会导致应用程序延迟显著增加，因此是系统性能分析的重要目标。在高负载下，磁盘成为瓶颈，导致CPU空闲，系统等待磁盘I/O完成。识别和消除瓶颈可以将性能和应用程序吞吐量提高数个数量级。术语“磁盘”指的是系统的主要存储设备。它们包括磁性旋转磁盘和基于闪存存储的固态硬盘（SSD）。后者主要是为了提高磁盘I/O性能而引入的，它们确实做到了。然而，对于容量和I/O速率的需求也在增加，闪存存储设备也不免遇到性能问题。本章包括五个部分，前三部分为磁盘I/O分析提供基础，后两部分展示了它在基于Linux和S
2024-06-22 12:40:58
23
翻译 8 File Systems
接下来的偏移8千字节的系统调用读取不会触发磁盘读取，因为它已经被缓存，而是触发了从偏移16开始的预读，以获取下一个34千字节的数据——50千字节文件的剩余部分。这提高了路径名查找的性能（例如，通过open()），因为在遍历路径名时，每个名称查找都可以检查Dcache以获取直接的索引节点映射，而不是逐个遍历目录内容。从磁盘设备级别的指标来看，这看起来令人担忧；其他确定性因素包括操作是随机的还是顺序的，是读取还是写入，是同步写入还是异步写入，它们的I/O大小，是否包含其他操作类型，以及它们的CPU执行成本。
2024-06-22 11:53:32
18
翻译 7 Memory
Linux提供了一种平衡这种行为的方式：swappiness，一个介于0和100之间的参数（默认值为60），更高的值偏向通过分页应用程序释放内存，而较低的值则通过从页面缓存中回收内存（类似于基于Solaris系统的行为）。例如，在基于 Solaris 的系统上实施 OS 虚拟化时，对于每个客户实例强制执行内存配额的机制不同，并将其与传统的页面扫描器报告的方式有所不同。在第6章“CPU”中，在CPU缓存下的延迟部分（第6.4.1节），展示了微基准测试内存访问延迟的结果，以确定CPU缓存的特性。
2024-06-22 09:44:02
14
翻译 6 CPUs
swtch()函数管理离开CPU的线程，包括出于自愿的上下文切换等任何原因，并调用调度程序函数来找到最适合替代它的可运行线程：disp()、disp_getwork()或disp_getbest()。作为对其预期含义的启示，在1979年由Bill Joy和Ozalp Babaoglu为3BSD编写的原始vmstat(1)以RQ列开始，用于表示可运行和正在运行的进程数量，就像目前的Linux vmstat(8)一样。无论您使用哪种基准测试，在比较系统之间的结果时，重要的是要了解真正被测试的内容。
2024-06-16 22:04:32
14
翻译 5 Applications
通常情况下，以单个I/O传输128K字节要比以128个1K字节的I/O传输更有效，考虑到任何固定的每个I/O的成本。这通常是开发人员的工作。然而，如果应用程序A是不透明的，而应用程序B提供了丰富的可观测性工具，长远来看，应用程序B很可能是更好的选择。在云计算中的操作系统虚拟化中，我们遇到过这个问题，一个应用程序可以看到所有CPU，然后假定自己是服务器上唯一的应用程序而将自身绑定到某些CPU。在NUMA环境中，让进程或线程保持在单个CPU上运行，并在执行I/O之后继续在同一CPU上运行，可能是有利的。
2024-06-16 21:16:49
19
翻译 4 Observability Tools
由于它是主线内核的一部分，如果已经存在，则可能是使用最简单的，并且可能提供足够的可观测性以回答您的许多问题。在某些系统上（特别是进程众多的系统），执行这些操作的开销可能会变得明显，特别是对于在每个屏幕更新时针对每个进程重复执行此序列的top(1)版本。例如，可以将lxproc挂载在/lxproc上，需要类似Linux的/proc的应用程序可以修改为从/lxproc加载进程信息，而不是/proc——这应该只是一个小的改动。使用SystemTap的开销与之前描述的DTrace类似，使用时需要注意相同的问题。
2024-06-10 17:29:03
14
翻译 3 Operating Systems
后者是由内核调度并在需要时可以睡眠的线程。最后发布的OpenSolaris版本，它镜像了Solaris 11的开发版本，成为开源的illumos内核的基础。这可以通过计算最近计算时间（在 CPU 上执行的时间）与实际时间（经过的时间）的比率，并降低具有较高（计算）比率的进程的优先级来实现[Thompson 78]。顶级目录包括etc（用于系统配置文件），usr（用于系统提供的用户级程序和库），dev（用于设备文件），var（用于包含系统日志等可变文件），tmp（用于临时文件）和home（用于用户主目录）。
2024-06-10 13:25:24
15
翻译 2 Methodology
在没有数据之前进行理论推测是一个严重的错误。不知不觉中，人们开始扭曲事实以适应理论，而不是调整理论以适应事实。阿瑟·柯南·道尔爵士的《波西米亚丑闻》中的福尔摩斯警句当面临性能下降和复杂的系统环境时，首要挑战是确定从哪里开始分析、收集哪些数据以及如何进行分析。正如我在第一章中所说，性能问题可能来自任何地方，包括软件、硬件和数据路径上的任何组件。方法论可以帮助性能分析人员处理复杂的系统，指导他们从何处开始，并采取哪些步骤来定位和分析性能问题。对于初学者，方法论指明了起点并提供了详细的步骤。对于普通用户或专家
2024-05-19 16:42:59
21
翻译 1 Introduction
Pamela想知道是否需要采取不同的方法，例如运行固定速率的操作，然后对资源使用情况（CPU、磁盘I/O、网络I/O）进行特征化(资源使用)，以便可以从单个客户端请求的角度来表示。如数据库团队所报道的，磁盘的利用率很高，约为80%，而对于其他资源（CPU、网络）的利用率则要低得多。以一秒的粒度，Scott可以看到磁盘利用率波动很大，经常达到100%，导致饱和度水平升高和增加的磁盘I/O延迟。Scott在工单中增加了更多细节，说明了他所检查的内容，并包括了研究磁盘所使用的命令的屏幕截图。
2024-05-19 16:18:13
15
翻译 Preface
这些工具通常以直观的方式呈现数据，许多工具的风格类似于早期的Unix工具，产生的输出是熟悉且常常不言自明的。虽然上述声明引起了出席新闻发布会的人们的笑声，但它总结了一个重要原则，这个原则在复杂的技术系统和地缘政治中同样适用：性能问题可能来自任何地方，包括您不知道且因此未检查的系统领域（未知未知）。对于每个读者群体来说，覆盖两种不同的操作系统提供了额外的视角，深入了解它们的特点，特别是在每个操作系统采取不同的设计路径时。技术的历史可以提供有用的见解，深化您的理解，在书中的一些地方已经提到了。
2024-04-07 23:32:11
24
翻译 Chapter5 INTERESTING CACHE TRICKS
每个缓存设计师都会在某个时候遇到由缓存设计方法引起的困难。可能是因为缓存无法包含原始设计中指定的所有最优雅的目标，或者可能存在实际约束，需要在一个领域使用离常规的策略，而现在在另一个领域存在逻辑上的后果。无论出于何种原因，所有设计师都知道几乎可以找到解决这类困境的答案，但通常需要以不同的方式思考问题。本章专门介绍了一些被各种处理器设计师用于改善特定情况下系统性能的技巧。在某些情况下，设计师利用系统划分来提高性能，在其他情况下，他们解决了由于选择了其他方法而引起的问题。这里展示的所有技巧都有点超出传统范畴，
2024-03-03 13:53:32
27
翻译 Chapter4 MAINTAINING COHERENCY IN CACHED SYSTEMS
经常引用的一项统计数据表明，夫妻间最常见的争吵原因是金钱问题。为什么这样的统计数据会出现在一本关于高速缓存设计的书中呢？因为某些金钱争论和缓存一致性问题之间存在着深刻而又务实的相似之处。让我们假设大多数金钱争议都以类似以下例子中的一种开始：“'你为什么不在支票登记册上记录当你从自动提款机取钱时的支出？现在我们反弹了三张支票！”“你在Visa账户上刷了900美元，却忘了告诉我？难怪在餐厅里当着我老板的面我的信用被拒绝了！”“那是我们准备去夏威夷的钱！”“那100美元现金到底发生了什么事情？”这些例
2024-03-03 12:49:13
24
翻译 Chapter3 CACHE MEMORIES AND RISC PROCESSORS
3.1 THE RISC CONCEPT现今的管理咨询师和商业作家告诫美国企业要抛弃古老格言和过去的老套方法，尝试不同的思维方式。这正是IBM T.J.沃森研究中心在1970年代末做的事情。在那个时候，半导体工艺的进步提供了越来越多的集成境遇，人们欢迎它作为增加CPU复杂性的手段。旧架构提供了简单的构造，例如使用简单寻址模式进行加载、存储和加法。随着更高的集成度，程序员可以提供单个指令，对基于多个内存操作符的运算对象进行乘除或执行简单级数逼近函数的子集，使用高度精密的寻址技术。这种方法很大程度上增加了代码
2024-03-03 12:34:07
24
翻译 Chapter2 HOW ARE CACHES DESIGNED?
在本章中，我们将研究缓存设计中使用的一些方法或“行业诀窍”。虽然没有特别复杂的设计技术被使用，但已经投入了大量思考来揭示显而易见的东西，典型的设计师最终将不得不记下许多针对缓存的经验法则，以便正确地进行缓存设计。2.1 THE CPU-TO-MAIN-MEMORY INTERFACE正如第一章所讨论的，CPU缓存实际上插入在CPU和系统主存储器之间。正因为如此，为了让缓存欺骗CPU，使其误以为缓存访问实际上是对主存储器的访问，并且没有其他操作，缓存必须匹配CPU和主存储器之间的接口。2.1.1 Why M
2024-03-02 12:39:25
20
原创 系统调用与系统库函数
Chatgpt]您是对的，即使在上述示例中使用了 `open`、`read` 和 `close` 系统调用，实际上编译后的程序也会链接到 C 标准库（libc）中的相应函数。[问]上述的open/read/close虽然是系统调用，但实际的linux程序编译时会使用libc.so封装的open/read/close函数，相当于还是linux应用程序先调用库函数，再调用系统调用呀？需要注意的是，直接调用系统调用可能会导致代码的可移植性下降，并且需要更多的关注和处理错误情况。
2023-12-09 18:27:32
421
翻译 Chapter1 WHAT IS A CACHE MEMORY?
1.1 CPU SPEED VS. SYSTEM SPEED问题很简单。设计师们不断努力以最具成本效益的方式发挥他们设计的最大潜力。当某个特定CPU的更快版本面世时，设计师通常会尝试通过简单地增加CPU时钟频率来提高现有设计的吞吐量。在某个点之后，系统的主存储器（有时称为后备存储器）的速度成为系统吞吐量的限制因素。这在图1.1中有所体现。X轴表示CPU时钟频率，Y轴表示系统的总吞吐量。对于这个例子，我们假设系统是计算受限的；也就是说，系统的性能受到CPU性能的限制，而不是输入/输出（I/O）设备（例如磁
2023-11-26 19:15:58
127
翻译 INTRODUCTION TO THE FIRST EDITION
由于缓存语言的独特性和技术的新颖性，一个严重的劣势就是术语处于不断变化的状态，你经常会看到在文本中使用的词汇被完全不同地使用，或者更糟的是，用不同的词来描述相同的功能。两种设备的操作原理类似，但是磁盘缓存通常是使用软件控制在动态RAM（DRAM）中实现的，而CPU缓存则以如此高的速度运行，必须使用硬件控制，并且缓存本身必须在静态RAM（SRAM）中实现。是的，有些操作，特别是创建一些更复杂的图形和重新排版文本，如果使用更好、更快的CPU和缓存的机器，速度会快得多，也不会那么令人沮丧。其实，缓存并不难理解。
2023-11-25 13:15:44
92
翻译 INTRODUCTION TO THE SECOND EDITION
不过，我选择保留最旧的一个缓存示例，在第一章中进行演示，以说明真实的缓存设计的门数并不高，而且不必回避缓存设计。最后，与我用来创建第一版的无缓存系统相反，第二版正在一台Windows 95机器上制作，该机器采用133 MHz Pentium处理器，有8KB的一级缓存和256KB的二级缓存。随着领域变得更加广泛，公司之间的交流变得更加频繁和开放，公司特定的行话被更标准化的行话所取代，人们发现自己需要发明一个新的行话之前，会先了解别人的行话。我还添加了一个新的第五章，展示了其他人是如何应对遇到的某些难题的。
2023-11-25 10:22:36
62
翻译 19 Literature
Intel：《IA-32 Intel Architecture Software Developer’s Manual》，第 1、2A、2B 和 3A 和 3B 卷。请参见 www.agner.org/optimize 和 comp.lang.asm.x86 新闻组的 FAQ 中的一些链接。包括在可从 www.intel.com 获取的 Intel C++ 编译器中。
2023-11-23 22:14:53
34
翻译 18 Optimization in embedded systems
在没有-fno-associative-math选项时，结果为0，在有-fassociative-math选项时，结果为1。例如: x*x可以优化为0. 如果x=INF，则结果将错误，因为INF-INF=NAN。-fno-math-errno: 不会为sqrt等函数设置errno的陷阱。这对于包含sqrt的分支的自动向量化是必要的。-fno-signed-zeros: 启用忽略零的符号的优化，例如x*0.0=0和x+0.0=x。
2023-11-23 22:12:59
61
翻译 17 Optimization in embedded systems
这通常属于系统编程领域，但在没有操作系统的应用程序中，这是应用程序员的工作。时钟频率可能低于标准个人计算机的百倍甚至千倍，RAM内存的数量甚至可能少于个人计算机的百万分之一。然而，如果避免使用大型图形框架、解释器、即时编译器、系统数据库以及其他在较大系统上常用的额外软件层和框架，就有可能在这些小型设备上运行相当快速的软件。如果想要计算一个具有两位小数的数字，例如，应该将其乘以100，以便表示为整数。程序员有责任确保数组足够大，可以处理包括终止零在内的字符串，并在必要时进行溢出检查（参见第105页）。
2023-11-23 21:55:08
26
翻译 16 Testing speed
一个时钟周期的长度是时钟频率的倒数，如第15页所解释的那样。如果在执行关键代码片段之前和之后读取时间戳计数器的值，那么您可以得到准确的时间消耗，即两个时钟计数之间的差异。通常的测试方法是创建一个小型的测试程序，使用适当的测试数据多次调用关键函数，并测量所需的时间。一个真实的性能测试应该包括不仅仅是一个单独的函数或热点，还应该包括包含关键函数和热点的最内层循环。偶尔，测量到的时钟计数远高于正常值。这种单元测试对于验证优化函数的功能是必要的，但不幸的是，单元测试并不能完全提供有关函数性能（速度）的全部信息。
2023-11-23 21:53:38
25
翻译 15 Metaprogramming
如果所有的输入都是已知的常量，一个好的优化编译器无论如何都会在编译时进行简单的计算，但是如果涉及到分支、循环、函数调用等更复杂的计算，很少有编译器能够在编译时进行。我认为除了简单的情况外，使用模板元编程是不明智的，因为复杂的代码本身就是一个风险因素，而验证、调试和维护此类代码的成本非常高昂，很少能够证明在性能上的收益是合理的。在C++的模板元编程中，循环被实现为递归模板。这是一种非常高效的方式来删除多余的代码，但是预处理器的功能有严重的限制，因为它在编译器之前起作用，并且只能理解最简单的表达式和运算符。
2023-11-23 21:48:08
20
翻译 14 Specific optimization topics
14.1 Use lookup tables如果一个常量表被缓存，那么从这个表中读取一个值是非常快的。通常从一级缓存中读取表只需要几个时钟周期。我们可以利用这个事实，如果一个函数的输入只有有限数量的情况，那么可以通过表查找来代替函数调用。以整数阶乘函数 (n!) 为例。它只允许输入区间 [0, 12] 中的整数。更大的输入会导致溢出，负数输入则产生无穷大。阶乘的典型实现如下：// Example 14.1aint factorial (int n) { // n!int i, f = 1;f
2023-11-22 23:04:35
31
翻译 13 Making critical code in multiple versions for different instruction sets
微处理器生产商不断向指令集添加新指令。这些新指令可以加快特定类型的代码执行速度。指令集中最重要的添加是第12章中提到的向量操作。如果代码针对特定的指令集进行编译，那么它将与支持该指令集或任何更高指令集的所有CPU兼容，但与早期的CPU不兼容。向后兼容的指令集序列如下所示：在手册4：“指令表”中提供了对指令集更详细的解释。根据第117页的说明，使用AVX或更高版本编译的代码与未使用AVX编译的代码存在一定的限制。使用最新的指令集的一个缺点是与旧微处理器的兼容性丧失。这个困境可以通过为不同的CPU制
2023-11-22 21:09:04
39
翻译 12 Using vector operations
使用长向量库的缺点是，如果你正在执行一个序列的计算，那么你必须在调用下一个步骤的函数之前将每个步骤的中间结果存储在一个临时数组中。short int的宽度为16位，而int的宽度为32位，因此，一个向量可以容纳8个short int类型的数字，而只能容纳4个int类型的数字。在AVX之前的指令集中，高效的向量操作要求数组的地址可被16整除。SSE2是向量类库支持的最低指令集，SSE4.1在select函数中具有优势，AVX2指令集具有更大的向量寄存器优势，而AVX512则具有更大的向量和更高效的分支操作。
2023-11-21 22:34:42
134
翻译 11 Out of order execution
最重要的是避免长的依赖链。它们可以检测到在示例11.3的循环的一个迭代中，寄存器temp的值与前一次迭代中的值无关。当前的CPU通常拥有一个或两个浮点加法单元，并且这些单元是流水线处理的，就像之前解释的那样，因此它可以在前一个加法完成之前启动新的加法操作。例如，在示例11.2b中，如果列表中的元素数目是奇数，那么我们需要在循环外部添加最后一个元素，或者在列表中添加一个额外的虚拟元素，并将该额外元素置零。一个迭代的计算中，除了循环计数器之外，不应该依赖于上一次迭代的结果（如果是整数，则计算速度很快）。
2023-11-21 22:25:49
33
翻译 10 Multithreading
在此，功能分解意味着不同的线程执行不同类型的工作。重要的是，用户界面不在同一个线程中作为非常耗时的任务，因为这将导致令人恼人的长而不规则的响应时间。例如，如果多个线程共享同一个队列、列表、数据库或其他数据结构，则可以考虑为每个线程提供自己的数据结构，然后在所有线程完成耗时的数据处理后将这些数据结构合并。缺点是如果线程使用不同的内存区域，缓存将被填满，并且如果线程对相同的内存区域进行写操作，就会发生缓存争用。在数据分解的情况下，最好没有更多具有相同优先级的线程，而是等于系统中可用的核心或逻辑处理器的数量。
2023-11-21 22:22:27
28
翻译 9 Optimizing memory access
9.1 Caching of code and data缓存是计算机中主内存的代理。这个代理比主内存小而且更接近CPU，因此访问速度更快。为了实现对最常用数据的最快访问，可能会有两个或三个级别的缓存。CPU的速度比RAM内存快得多。因此，高效的缓存对于系统性能非常重要。9.2 Cache organization如果您正在编写具有非顺序访问和需要避免缓存争用的大型数据结构的程序，了解缓存的组织方式是非常有用的。如果您满意更加经验性的准则，可以跳过本节。大多数缓存被组织为行和组。让我通过一个例子来解释。我
2023-11-21 22:20:26
34
Systems.Performance.Enterprise.and.the.Cloud.2013.10
2024-06-23
DDI0487J-a-a-profile-architecture-reference-manual
2024-06-23
arm-cortex-a715-core-software-optimization-guide
2024-06-23
Performance Analysis and Tuning on Modern CPUs
2024-01-12
start_kernel.xmind
2020-02-15
start_kernel.xmind
2020-02-05
JNI函数接口大全工程实例.zip
2019-08-26
Learning QGIS 2.0
2015-12-13
High efficiency video coding (HEVC) text specification draft 8
2015-07-28
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人