以下是我的假设：
- 有两种类型的加载，缓存和未缓存。在第一个方案中，业务通过L1和L2，而在第二个方案中业务仅通过L2
- Compute Capability 6.x和7.x中的默认行为是缓存访问
- 一个L1缓存行是128字节，一个L2缓存行是32字节，因此对于生成的每个L1事务，应该有四个L2事务(每个扇区一个(
- 在Nsight中，SM->TEX请求是指从32个线程合并而来的扭曲级指令。L2->TEX退货和TEX->SM返回是衡量每个内存单元之间传输的扇区数量的指标
假设计算能力为7.5，以下是我的问题：
- 第三个假设似乎暗示L2->对于全局缓存加载，TEX返回应该始终是四的倍数，但情况并非总是如此。这里发生了什么
- 用const和__restrict__限定符标记指针还有意义吗？这曾经是编译器的一个提示，即数据是只读的，因此可以缓存在L1/纹理缓存中，但现在所有数据都缓存在那里，包括只读和非只读
- 根据我的第四个假设，我认为每当TEX->SM返回大于L2->TEX返回，差异来自缓存命中。这是因为当缓存命中时，会从L1读取一些扇区，但没有从L2读取。这是真的吗
CC 6.x/7.x
- 一级缓存行大小为128字节，分为4个32字节扇区。在未命中的情况下，将仅从L2提取寻址扇区
- L2高速缓存行大小为128字节，划分为4个32字节扇区。
- CC 7.0(HBM(64B升级已启用。如果高速缓存行的低位64字节未命中，则低位64字节将从DRAM中取出。如果高速缓存行的高位64字节未命中，则将提取高位64字节
- 只有CC 6.x/7.5访问的32B扇区将从DRAM中取出
- 在一级缓存策略方面
- CC 6.0默认启用了负载缓存
- 默认情况下，CC 6.x已禁用负载缓存-请参阅编程指南
- CC 7.x默认启用了负载缓存-有关缓存控制的详细信息，请参阅PTX
在Nsight Compute中，术语请求在6.x和7.x之间变化。
- 对于5.x-6.x，每条指令的请求数因操作类型和数据宽度而异。例如，32位负载是8个线程/请求，64位负载是4个线程/要求，128位负载是2个线程/申请
- 对于7.x，请求应该等同于指令，除非访问模式具有导致序列化的地址分歧
回答CC 7.5问题
- 第三个假设似乎暗示L2->对于全局缓存加载，TEX返回应该始终是四的倍数，但事实并非如此总是这样。这里发生了什么
L1TEX单元将只获取缓存行中丢失的32B扇区。
- 用const和restrict限定符标记指针还有意义吗？这曾经是对编译器的提示，即数据是只读的，因此可以缓存在L1/纹理缓存中，但现在所有的数据都缓存在那里，既有只读的，也有非只读的
如果已知数据是只读的，编译器可以执行额外的优化。
- 请参阅PTX缓存运算符
- 请参阅PTX内存一致性模型
- 根据我的第四个假设，我认为无论何时TEX->SM返回大于L2->TEX返回，差异来自缓存命中。这是因为当缓存命中时，你会得到一些扇区从L1读取，但没有从L2读取。这是真的吗
L1TEX到SM的返回B/W为128B/周期。L2到SM的返回B/W在32B扇区中。
Nsight计算内存工作负载分析|L1/TEX缓存表显示
- 扇区未命中L2(32B扇区(
- 返回SM(周期==1-128B(