我试图在L1缓存中获得全部带宽,以便在Intel处理器上实现以下功能
float triad(float *x, float *y, float *z, const int n) {
float k = 3.14159f;
for(int i=0; i<n; i++) {
z[i] = x[i] + k*y[i];
}
}
这是STREAM的三合一功能.
使用具有此功能的SandyBridge/IvyBridge处理器可获得约95%的峰值(使用NASM组装).但是,除非我展开循环,否则使用Haswell I仅达到峰值的62%.如果我展开16次,我得到92%.我不明白这一点.
我决定使用NASM在汇编中编写我的函数.装配中的主循环看起来像这样.
.L2:
vmovaps ymm1, [rdi+rax]
vfmadd231ps ymm1, ymm2, [rsi+rax]
vmovaps [rdx+rax], ymm1
add rax, 32
jne .L2
在示例12.7-12.11 中的Agner Fog的优化组装手册中,他y[i] = y[i] +k*x[i]对Pentium M,Core 2,Sandy Bridge,FMA4和FMA3 做了几乎相同的事情(但是).我设法或多或少地自己重现了他的代码(实际上他在广播时在FMA3示例中有一个小错误).除FMA4和FMA3外,他为每个处理器的表格提供指令大小计数,融合操作,执行端口.我曾试图为FMA3制作这张桌子.
ports
size ?ops-fused 0 1 2 3 4 5 6 7
vmovaps 5 1 ½ ½ …我使用英特尔®架构代码分析器(IACA)发现了一些意想不到的东西(对我而言).
以下指令使用[base+index]寻址
addps xmm1, xmmword ptr [rsi+rax*1]
根据IACA没有微熔丝.但是,如果我用[base+offset]这样的
addps xmm1, xmmword ptr [rsi]
IACA报告它确实融合了.
英特尔优化参考手册的第2-11节给出了以下"可以由所有解码器处理的微融合微操作"的示例
FADD DOUBLE PTR [RDI + RSI*8]
和Agner Fog的优化装配手册也给出了使用[base+index]寻址的微操作融合的例子.例如,请参见第12.2节"Core2上的相同示例".那么正确的答案是什么？
我发现在MSVC(在Windows上)和GCC(在Linux上)为Ivy Bridge系统编译的代码之间的性能差异很大.代码执行密集矩阵乘法.我使用GCC获得了70%的峰值失误,而MSVC只获得了50%.我想我可能已经把他们两个内在函数如何转换的差异分开了.
__m256 breg0 = _mm256_loadu_ps(&b[8*i])
_mm256_add_ps(_mm256_mul_ps(arge0,breg0), tmp0)
GCC这样做
vmovups ymm9, YMMWORD PTR [rax-256]
vmulps ymm9, ymm0, ymm9
vaddps ymm8, ymm8, ymm9
MSVC这样做
vmulps ymm1, ymm2, YMMWORD PTR [rax-256]
vaddps ymm3, ymm1, ymm3
有人可以向我解释这两种解决方案是否以及为何能够在性能上产生如此大的差异？
尽管MSVC使用少一条指令,但它会将负载与多线程联系起来,这可能会使它更加依赖(也许负载无法按顺序完成)？我的意思是Ivy Bridge可以在一个时钟周期内完成一个AVX加载,一个AVX mult和一个AVX加载,但这要求每个操作都是独立的.
也许问题出在其他地方？您可以在下面看到最里面循环的GCC和MSVC的完整汇编代码.你可以在这里看到循环的C++代码循环展开以实现Ivy Bridge和Haswell的最大吞吐量
g ++ -S -masm = intel matrix.cpp -O3 -mavx -fopenmp
.L4:
vbroadcastss ymm0, DWORD PTR [rcx+rdx*4]
add rdx, 1
add rax, 256
vmovups ymm9, YMMWORD PTR [rax-256]
vmulps ymm9, ymm0, ymm9
vaddps ymm8, ymm8, ymm9
vmovups ymm9, YMMWORD PTR [rax-224] …我熟悉数据对齐和性能，但对对齐代码相当陌生。我最近开始使用 NASM 在 x86-64 汇编中进行编程，并一直使用代码对齐来比较性能。据我所知，NASM 插入nop指令来实现代码对齐。
这是我一直在 Ivy Bridge 系统上尝试的一个功能
void triad(float *x, float *y, float *z, int n, int repeat) {
float k = 3.14159f;
int(int r=0; r<repeat; r++) {
for(int i=0; i<n; i++) {
z[i] = x[i] + k*y[i];
}
}
}
我为此使用的程序集如下。如果我不指定对齐方式，我的性能与峰值相比仅为 90% 左右。然而，当我将循环之前的代码以及两个内部循环对齐为 16 字节时，性能跃升至 96%。很明显，这种情况下的代码对齐会产生影响。
但这是最奇怪的部分。如果我将最里面的循环对齐到 32 字节，则该函数的性能没有任何差异，但是，在该函数的另一个版本中，在单独的对象文件中使用内部函数，我链接它的性能从 90% 跃升至 95%！
我做了一个对象转储（使用objdump -d -M intel）的版本对齐到16字节（我将结果发布到这个问题的末尾）和32字节，它们是相同的！事实证明，在两个目标文件中，最里面的循环无论如何都与 32 字节对齐。但一定有一些区别。
我对每个目标文件进行了十六进制转储，目标文件中有一个字节不同。与 16 字节对齐的目标文件有一个带有 的字节0x10，与 32 字节对齐的目标文件有一个带有 的字节0x20。到底是怎么回事！为什么一个目标文件中的代码对齐会影响另一个目标文件中函数的性能？我如何知道将我的代码调整到的最佳值是多少？
我唯一的猜测是，当加载程序重新定位代码时，32 字节对齐的对象文件会使用内在函数影响其他对象文件。 …
align 64使用 来设置某些汇编器功能代码的最简单方法是什么ml64.exe？默认对齐方式_TEXT为 16，因此ml64不允许在align命令中设置超过 16。并且ml64不允许更改 的对齐方式_TEXT。
可以创建另一个部分/段，但是我们可以64 byte在主_TEXT部分中对齐吗？
有什么解决办法吗？
PS 解决方案建议在答案中_TEXT$FOO有效！
_TEXT$FOO SEGMENT ALIGN(64)
align 64
_TEXT$FOO ENDS
Characteristics我还尝试在十六进制编辑器中更改 obj (coff) 文件中的节标题中的对齐字段中的值_TEXT。链接器使用了改变的对齐方式。_TEXT那么，如果链接器可以使用 obj 文件中该字段的任何值，为什么 ml 和 jwasm 不允许更改 的默认 16 字节呢？
在某些情况下，64 字节对齐对于代码很有用。如果您使用 16 字节对齐，则另一个代码（可以是Ccode）可以随机将您的asm代码移动 4 个不同的偏移量：0、16、32、48。并且某些循环可能可以跨越 64 字节或 32 字节范围。asm因此，当您更改另一个代码时，您可以看到代码性能的一些不可预测的变化C。