相关疑难解决方法(0)

简而言之：

我已经实现了一个简单的（多键）哈希表，其中包含完全适合缓存行的存储桶（包含多个元素）。插入缓存行存储桶非常简单，也是主循环的关键部分。

我已经实现了三个版本，它们产生相同的结果并且行为应该相同。

谜

然而，尽管所有版本都具有完全相同的缓存行访问模式并产生相同的哈希表数据，但我发现性能差异惊人地大到了 3 倍。

与我的 CPU (i7-7700HQ)相比，最佳实现insert_ok速度慢了大约 3 倍。一个变体 insert_bad 是一种简单的修改，它在缓存行中添加了额外的不必要的线性搜索，以找到要写入的位置（它已经知道），并且不会遭受 3 倍的减速。insert_badinsert_altinsert_ok

与其他 CPU（AMD 5950X (Zen 3)、Intel i7-11800H (Tiger Lake)）相比，完全相同的可执行文件显示insert_ok速度快 1.6 倍。insert_badinsert_alt

# see https://github.com/cr-marcstevens/hashtable_mystery
$ ./test.sh
model name      : Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
==============================
CXX=g++    CXXFLAGS=-std=c++11 -O2 -march=native -falign-functions=64
tablesize: 117440512 elements: 67108864 loadfactor=0.571429
- test insert_ok : 11200ms
- test insert_bad: 3164ms
  (outcome identical to insert_ok: true)
- test insert_alt: 3366ms
  (outcome identical …

如果你有一个输入数组和一个输出数组,但是你只想写那些通过某个条件的元素,那么在AVX2中这样做最有效的方法是什么？

我在SSE看到它是这样做的:(来自:https://deplinenoise.files.wordpress.com/2015/03/gdc2015_afredriksson_simd.pdf)

__m128i LeftPack_SSSE3(__m128 mask, __m128 val)
{
 // Move 4 sign bits of mask to 4-bit integer value.
 int mask = _mm_movemask_ps(mask);
 // Select shuffle control data
 __m128i shuf_ctrl = _mm_load_si128(&shufmasks[mask]);
 // Permute to move valid values to front of SIMD register
 __m128i packed = _mm_shuffle_epi8(_mm_castps_si128(val), shuf_ctrl);
 return packed;
}

这对于4宽的SSE来说似乎很好,因此只需要16个入口LUT,但对于8宽的AVX,LUT变得非常大(256个条目,每个32个字节或8k).

我很惊讶AVX似乎没有简化此过程的指令,例如带有打包的蒙版存储.

我想通过稍微改变来计算左边设置的符号位数,你可以生成必要的排列表,然后调用_mm256_permutevar8x32_ps.但这也是我认为的一些指示......

有没有人知道用AVX2做这个的任何技巧？或者什么是最有效的方法？

以下是上述文件中左包装问题的说明:

谢谢

当我尝试测量算术运算的执行时间时，我遇到了非常奇怪的行为。包含for循环体中具有一个算术运算的循环的代码块总是比相同的代码块执行得慢，但在for循环体中具有两个算术运算。这是我最终测试的代码：

#include <iostream>
#include <chrono>

#define NUM_ITERATIONS 100000000

int main()
{
    // Block 1: one operation in loop body
    {
        int64_t x = 0, y = 0;
        auto start = std::chrono::high_resolution_clock::now();

        for (long i = 0; i < NUM_ITERATIONS; i++) {x+=31;}

        auto end = std::chrono::high_resolution_clock::now();
        std::chrono::duration<double> diff = end-start;
        std::cout << diff.count() << " seconds. x,y = " << x << "," << y << std::endl;
    }

    // Block 2: two operations in loop …

如果我有一个受Intel jcc erratum约束的芯片，我如何在 gcc 中启用缓解（它调整分支位置以避免有问题的对齐），以及哪些 gcc 版本支持它？

我正在尝试针对特定的 Kaby Lake CPU (i5-7300HQ) 优化以下子例程，理想情况下，与原始形式相比，代码速度至少快 10 倍。该代码在 16 位实模式下作为软盘式引导加载程序运行。它在屏幕上显示一个十位数的十进制计数器，从 0 - 9999999999 计数然后停止。

我查看了 Agner 的微体系结构和汇编优化指南、 指令性能表和英特尔的优化参考手册。

到目前为止，我能够做的唯一明智的优化是将loop指令交换为dec + jnz，在此处进行解释。

另一种可能的优化可能是交换lodsbfor mov + dec，但我发现的关于它的信息一直存在冲突，有些人说它有一点帮助，而另一些人则认为它实际上可能会损害现代 CPU 的性能。

我还尝试切换到 32 位模式并将整个计数器保留在一个未使用的寄存器对中以消除任何内存访问，但在读入一点后我意识到这十位将立即被缓存，并且 L1 缓存之间的延迟差异和寄存器只有大约三倍，所以绝对不值得以这种格式使用计数器的额外开销。

（编者注：add reg延迟为 1 个周期，add [mem]延迟约为 6 个周期，包括 5 个周期的存储转发延迟。如果[mem]像视频 RAM 那样不可缓存，则更糟。）

org 7c00h

pos equ 2*(2*80-2)  ;address on screen

;init
cli
mov ax,3
int 10h
mov …

今天我发现示例代码在添加了一些不相关的代码后速度降低了 50%。调试后我发现问题出在循环对齐上。根据循环代码的放置，有不同的执行时间，例如：

之前没想到代码对齐会有这么大的影响。我认为我的编译器足够聪明，可以正确对齐代码。

究竟是什么导致了执行时间的如此大的差异？（我想一些处理器架构细节）。

我用 Visual Studio 2019 在 Release 模式下编译的测试程序并在 Windows 10 上运行它。我在 2 个处理器上检查了程序：i7-8700k（上面的结果）和 intel i5-3570k 但问题不存在在那里，执行时间总是大约 1250us。我也试过用 clang 编译程序，但结果总是 ~1500us（在 i7-8700k 上）。

我的测试程序：

#include <chrono>
#include <iostream>
#include <intrin.h>
using namespace std;

template<int N>
__forceinline void noops()
{
    __nop(); __nop(); __nop(); __nop(); __nop(); __nop(); __nop(); __nop(); __nop(); __nop(); __nop(); __nop(); __nop(); __nop(); __nop(); __nop();
    noops<N - 1>();
}
template<>
__forceinline void noops<0>(){}

template<int OFFSET>
__declspec(noinline) void SumHorizontalLine(const …

我正在尝试使用我的 Intel i7-10700 和 ubuntu 20.04 来验证两个可熔断对可以在同一时钟周期内解码的结论。

测试代码排列如下，复制了8000次左右，以避免LSD和DSB的影响（主要使用MITE）。

ALIGN 32
.loop_1:
    dec ecx
    jge .loop_2
.loop_2:
    dec ecx
    jge .loop_3
.loop_3:
    dec ecx
    jge .loop_4
.loop_4:
.loop_5:
    dec ecx
    jge .loop_6

测试结果表明，单个循环中仅融合一对。( r479 div r1002479 )

 Performance counter stats for process id '22597':

   120,459,876,711      cycles                                                      
    35,514,146,968      instructions     #    0.29  insn per cycle         
    17,792,584,278      r479             # r479: Number of uops delivered                     
                                         # to Instruction Decode Queue (IDQ) from MITE path                                  
        50,968,497      r4002479        
                                         
                                                  
    17,756,894,879      r1002479         # r1002479: Cycles MITE is …

考虑一个简单的指令，例如

mov RCX, RDI          # 48 89 f9

48 是 x86_64 的 REX 前缀。它不是LCP。但请考虑添加 LCP（用于对齐目的）：

.byte 0x67
mov RCX, RDI          # 67 48 89 f9

67 是地址大小前缀，在本例中用于没有地址的指令。该指令也没有立即数，并且不使用 F7 操作码（假 LCP 停止；F7 将是 TEST、NOT、NEG、MUL、IMUL、DIV + IDIV）。假设它也不跨越 16 字节边界。这些是 Intel优化参考手册中提到的 LCP 停顿情况。

该指令是否会导致 LCP 停顿（在 Skylake、Haswell 等上）？两个 LCP 怎么样？

我日常驾驶的是 MacBook。所以我无法访问 VTune，也无法查看 ILD_STALL 事件。还有其他方法可以知道吗？

英特尔推送微码更新以修复名为“跳转条件代码 (JCC) 勘误表”的错误。由于在某些条件下禁用将代码放入 ICache，更新微码导致某些操作效率低下。

已发布的文档，标题为跳转条件代码勘误的缓解措施不仅列出了JCC，还列出了：无条件跳转、条件跳转、宏融合条件跳转、调用和返回。

MSVC 开关/QIntel-jcc-erratum文档提到：

在 /QIntel-jcc-erratum 下，编译器检测跨越或结束于 32 字节边界的跳转和宏融合跳转指令。

问题是：

• 是否有理由将 JCC 与其他跳转分开处理？
• 是否有理由将宏融合 JCC 与其他 JCC 分开处理？

我目前正在自学 SIMD 并且正在编写一个相当简单的字符串处理子程序。然而，我仅限于 SSE2，这使我无法利用 ptest 找到空终端。

我目前试图找到空终端的方式使我的 SIMD 循环有 >16 条指令，这违背了使用 SIMD 的目的 - 或者至少使它不那么值得。

//Check for null byte
pxor xmm4, xmm4
pcmpeqb xmm4, [rdi]                                   //Generate bitmask
movq rax, xmm4
test rax, 0xffffffffffffffff                          //Test low qword
jnz .Lepilogue
movhlps xmm4, xmm4                                    //Move high into low qword
movq rax, xmm4
test rax, 0xffffffffffffffff                          //Test high qword
jz .LsimdLoop                                         //No terminal was found, keep looping

我想知道在没有 ptest 的情况下是否有任何更快的方法可以做到这一点，或者这是否是最好的方法，我将不得不再优化循环的其余部分。

注意：我确保输入使用 SIMD 的循环的字符串地址是 16B 对齐的，以允许对齐的指令。