|
1
22
相关的: what is a store buffer? 和一个基本的/初学者友好的介绍缓冲区的概念 can a speculatively executed cpu branch contain opcodes that access RAM? 而且 How do the store buffer and Line Fill Buffer interact with each other? 很好地描述了执行存储指令的步骤,以及它最终如何提交到L1d缓存。 整个存储缓冲区由多个条目组成 . 每个核心都有自己的存储缓冲区 1. 将执行和退出从提交分离到L1d缓存。即使是有序的CPU也能从存储缓冲区中获益,以避免在缓存未命中存储时暂停,因为与加载不同,它们只需要变得可见 最后 (没有实用的CPU使用顺序一致性内存模型,因此至少允许StoreLoad重新排序,即使在x86和SPARC-TSO中也是如此)。 对于推测性/无序CPU,它还可以在检测到旧指令中的异常或其他错误推测后回滚存储,而不会使推测性存储在全局可见。这显然对正确性至关重要!(你不能回滚其他内核,所以在知道存储数据是非推测性的之前,你不能让它们看到你的存储数据。) 当两个逻辑核都处于活动状态(超读)时,英特尔将存储缓冲区分成两部分;每个逻辑核得到一半。从一个逻辑内核加载时,只会窥探它自己的一半存储缓冲区 2. . What will be used for data exchange between threads are executing on one Core with HT?
存储缓冲区从中提交数据
已退休的
以程序顺序(尊重x86的强顺序内存模型)尽可能快地将指令存储到L1d中
3.
).要求门店承诺
像
他们退休会不必要地拖延商店的退休时间。仍在存储缓冲区中的退役存储肯定会发生,并且无法回滚,因此它们实际上可能会影响中断延迟。(从技术上讲,中断不需要序列化,但IRQ处理程序所做的任何存储在现有挂起的存储耗尽之前都无法显示。以及
这是一个常见的(?)错误地认为必须显式刷新数据才能让其他线程看到数据。记忆障碍不会 原因 要刷新的存储缓冲区, 完整的屏障构成了当前的核心 等待 直到存储缓冲区自行耗尽 ,然后再进行任何后续加载(即读取L1d)。原子RMW操作必须等待存储缓冲区耗尽,然后才能锁定缓存线,并将其加载和存储到该缓存线,而不允许它离开MESI修改状态,从而阻止系统中的任何其他代理在原子操作期间观察它。
为了实现x86的强有序内存模型,同时仍然在微体系结构上允许早期/无序加载(并在体系结构允许加载时检查数据是否仍然有效),加载缓冲区+存储缓冲区条目共同构成
内存顺序缓冲区(MOB)
如果缓存线
不是吗
当允许加载时仍然存在,这是内存顺序错误推测。)这个结构大概就是
英特尔CPU上的存储指令解码以存储地址和存储数据UOP (微熔合成一个熔合域uop)。存储地址uop只是将地址(可能还有存储宽度)写入存储缓冲区,以便以后加载时可以设置存储->加载转发或检测它们是否重叠。存储数据uop写入数据。 存储地址和存储数据可以按任意顺序执行,以先准备好的为准:分配/重命名阶段将UOP从前端写入ROB,并将RS写入后端 在发布时为加载或存储UOP分配加载或存储缓冲区 .或在有空之前暂停。由于分配和提交是按顺序进行的,这可能意味着更老/更年轻的条目很容易跟踪,因为它可以只是一个循环缓冲区,不必担心旧的长寿命条目在包装后仍在使用。(除非缓存绕过/弱有序NT存储可以做到这一点?它们可以无序提交到LFB(行填充缓冲区)。与普通存储不同,它们直接提交给LFB进行核心外转移,而不是L1d。)
存储缓冲区大小是以条目而不是位来度量的。窄存储区不会在存储缓冲区中“使用更少的空间”,它们仍然只使用一个条目。 Skylake的存储缓冲区有56个条目( wikichip )从哈斯韦尔/布罗德韦尔的42个增加到 ,在SnB/IvB中为36( David Kanter's HSW writeup on RealWorldTech has diagrams) .你可以在坎特在RWT上的writeups、Wikichip的图表或各种其他来源中找到大多数早期x86 UARCH的数字。 SKL/BDW/HSW还有72个加载缓冲区条目,SnB/IvB有64个。这是尚未执行或正在等待数据从外部缓存到达的飞行中加载指令数。 以比特为单位的大小 每个 条目是一个实现细节,对优化软件的方式没有任何影响。类似地,我们不知道uop的大小(在前端、ROB、RS中)或TLB实现细节,或许多其他事情,但我们知道有多少ROB和RS条目,以及在各种UARCH中有多少不同类型的TLB条目。 英特尔不发布CPU设计的电路图,而且(AFAIK)这些尺寸通常不为人所知,因此我们甚至无法满足对设计细节/权衡的好奇心。 在存储缓冲区中写入合并:背对背将存储缩小到同一缓存线可以(可能?)在它们提交之前合并到存储缓冲区中,因此在L1d缓存的写入端口上可能只需要一个周期就可以提交多个存储。 我们肯定知道一些非x86 CPU会这样做,我们有一些证据/理由怀疑英特尔CPU可能会这样做。但如果真的发生了,这是有限的@BeeOnRope和我目前认为Intel CPU可能 不要 做任何重要的合并。如果他们这样做了,最合理的情况是,存储缓冲区末尾的条目(准备提交到L1d)可能会合并到一个缓冲区中,如果我们正在等待该缓存线的RFO,则会优化提交。请参见评论中的讨论 Are two store buffer entries needed for split line/page stores on recent Intel? .我提出了一些可能的实验,但还没有做。 关于可能的存储缓冲区合并的早期内容: 请参见以此评论开始的讨论: Are write-combining buffers used for normal writes to WB memory regions on Intel? 而且 Unexpectedly poor and weirdly bimodal performance for store loop on Intel Skylake 可能是相关的。 我们可以肯定地知道,一些弱有序的ISA,比如Alpha 21264,确实在它们的存储缓冲区中存储了聚合,因为 the manual documents it ,以及它对每个周期可以向L1d提交和/或从L1d读取的内容的限制。此外,PowerPC RS64-II和RS64-III在以下评论链接的文档中的详细信息较少: Are there any modern CPUs where a cached byte store is actually slower than a word store? 人们发表了关于如何做(更具攻击性?)的论文在TSO内存模型(如x86)中存储合并,例如。 Non-Speculative Store Coalescing in Total Store Order 如果将存储缓冲区条目的数据复制到同一行,则合并可以允许在其数据提交到L1d之前释放存储缓冲区条目(可能只有在退役之后)。只有当没有其他行的存储区将它们分开时,才会发生这种情况,否则会导致存储区按程序顺序提交(变得全局可见),从而违反内存模型。但我们认为这可能发生在同一行的任意两个存储中,甚至是第一个和最后一个字节。 这种想法的一个问题是,SB条目分配可能是一个环形缓冲区,就像ROB一样。无序发布条目意味着硬件需要扫描每个条目以找到一个免费条目,如果它们被无序重新分配,那么它们就不符合以后商店的程序顺序。这可能会使分配和存储转发变得更加困难,所以这可能是不合理的。 如中所述 在最近的英特尔上,拆分行/页存储是否需要两个存储缓冲区条目? ,即使SB条目跨越缓存线边界,也可以保存一个存储的所有内容。当提交到上的L1d缓存时,缓存线边界变得相关 离开 这个人是某人。我们知道,存储转发可以用于跨缓存线拆分的存储。如果它们在存储端口中被拆分为多个SB条目,这似乎不太可能。 术语: 我一直在用“合并”来讨论在存储缓冲区中合并,而用“写入合并”来讨论在(希望)不使用RFO进行整行写入之前在LFB中合并的NT存储。或者存储到具有相同功能的WC内存区域。 这种区别/惯例只是我编造的。根据评论中的讨论,这可能不是标准的计算机架构术语。 英特尔的手册(尤其是优化手册)是由不同的作者多年编写的,在术语上也不一致。 对优化手册的大部分内容持保留态度,尤其是在谈到奔腾4时。关于Sandybridge和Haswell的新章节是可靠的,但旧的部分可能有过时的建议,这些建议只/主要与P4有关(例如inc与add 1),或者对一些优化规则的微体系结构解释可能令人困惑/错误。尤其是第3.6.10节。在等待缓存未命中存储到WB内存的队列到达时,使用LFB合并存储的第一个要点似乎并不合理,因为内存排序规则。请参阅我和上文链接的BeeOnRope之间的讨论,以及这里的评论。 脚注1: 从内部缓存到缓冲区回写(或直写)的写组合缓存将具有不同的名称。e、 g.推土机系列使用16k直写L1d缓存,带有一个小的4k写回缓冲区。(见 Why do L1 and L2 Cache waste space saving the same data? 详细信息和更多详细信息的链接。看见 Cache size estimation on your system? 在推土机系列CPU上,重写一个速度超过4k的阵列微基准。) 脚注2 :一些POWER CPU允许其他SMT线程在存储缓冲区中窥探失效的存储:这可能会导致不同线程对其他线程存储的全局顺序产生分歧。 Will two atomic writes to different locations in different threads always be seen in the same order by other threads? 脚注3 :具有弱内存模型的非x86 CPU可以以任何顺序提交失效的存储,允许更积极地将多个存储合并到同一行,并使缓存未命中存储不会暂停提交其他存储。 |
|
Sweepy Dodo · JSON lite的格式化 1 年前 |
|
|
giantjenga · 优化整数向量到二进制向量的转换 1 年前 |
|
Zegarek · Postgresql递归查询未提供预期结果 1 年前 |
|
|
Joe · 为什么这两个查询之间的性能存在如此大的差异? 2 年前 |
|
tic-toc-choc · 在`dplyr中高效使用列表进行过滤` 2 年前 |