为什么我不使用get_unchecked（）来提升性能？

Question

我尝试使用get_unchecked()代替[]索引运算符来提高des包的s()函数的性能。

但是，即使[]（或get_unchecked()）函数在我的基准测试中被称为48亿次，也不会导致性能明显改善。我原本认为拨打get_unchecked() 48亿次而不是[]会使我的英特尔酷睿2双核2.4 GHz处理器的时间缩短2秒。

我制作了这个小基准，有一个小代码可以告诉你：

#![feature(test)]

extern crate test;

fn main() {
}

pub fn s(box_id: usize, block: u64) -> u64 {
    const TABLES: [[[u64; 16]; 4]; 8] =
        [[[ 14,  4, 13, 1,  2, 15, 11,  8,  3, 10,  6, 12,  5,  9, 0, 7]
        , [  0, 15,  7, 4, 14,  2, 13,  1, 10,  6, 12, 11,  9,  5, 3, 8]
        , [  4,  1, 14, 8, 13,  6,  2, 11, 15, 12,  9,  7,  3, 10, 5, 0]
        , [ 15, 12,  8, 2,  4,  9,  1,  7,  5, 11,  3, 14, 10,  0, 6, 13]
        ],
        [ [ 15,  1,  8, 14,  6, 11,  3,  4,  9, 7,  2, 13, 12, 0,  5, 10]
        , [  3, 13,  4,  7, 15,  2,  8, 14, 12, 0,  1, 10,  6, 9, 11,  5]
        , [  0, 14,  7, 11, 10,  4, 13,  1,  5, 8, 12,  6,  9, 3,  2, 15]
        , [ 13,  8, 10,  1,  3, 15,  4,  2, 11, 6,  7, 12,  0, 5, 14,  9]
        ],
        [ [ 10,  0,  9, 14, 6,  3, 15,  5,  1, 13, 12,  7, 11,  4,  2,  8]
        , [ 13,  7,  0,  9, 3,  4,  6, 10,  2,  8,  5, 14, 12, 11, 15,  1]
        , [ 13,  6,  4,  9, 8, 15,  3,  0, 11,  1,  2, 12,  5, 10, 14,  7]
        , [  1, 10, 13,  0, 6,  9,  8,  7,  4, 15, 14,  3, 11,  5,  2, 12]
        ],
        [ [  7, 13, 14, 3,  0,  6,  9, 10,  1, 2, 8,  5, 11, 12,  4, 15]
        , [ 13,  8, 11, 5,  6, 15,  0,  3,  4, 7, 2, 12,  1, 10, 14,  9]
        , [ 10,  6,  9, 0, 12, 11,  7, 13, 15, 1, 3, 14,  5,  2,  8,  4]
        , [  3, 15,  0, 6, 10,  1, 13,  8,  9, 4, 5, 11, 12,  7,  2, 14]
        ],
        [ [  2, 12,  4,  1,  7, 10, 11,  6,  8,  5,  3, 15, 13, 0, 14,  9]
        , [ 14, 11,  2, 12,  4,  7, 13,  1,  5,  0, 15, 10,  3, 9,  8,  6]
        , [  4,  2,  1, 11, 10, 13,  7,  8, 15,  9, 12,  5,  6, 3,  0, 14]
        , [ 11,  8, 12,  7,  1, 14,  2, 13,  6, 15,  0,  9, 10, 4,  5,  3]
        ],
        [ [ 12,  1, 10, 15,  9,  2,  6,  8,  0, 13,  3,  4, 14,  7,  5, 11]
        , [ 10, 15,  4,  2,  7, 12,  9,  5,  6,  1, 13, 14,  0, 11,  3,  8]
        , [  9, 14, 15,  5,  2,  8, 12,  3,  7,  0,  4, 10,  1, 13, 11,  6]
        , [  4,  3,  2, 12,  9,  5, 15, 10, 11, 14,  1,  7,  6,  0,  8, 13]
        ],
        [ [  4, 11,  2, 14, 15, 0,  8, 13,  3, 12, 9,  7,  5, 10, 6,  1]
        , [ 13,  0, 11,  7,  4, 9,  1, 10, 14,  3, 5, 12,  2, 15, 8,  6]
        , [  1,  4, 11, 13, 12, 3,  7, 14, 10, 15, 6,  8,  0,  5, 9,  2]
        , [  6, 11, 13,  8,  1, 4, 10,  7,  9,  5, 0, 15, 14,  2, 3, 12]
        ],
        [ [ 13,  2,  8,  4,  6, 15, 11,  1, 10,  9,  3, 14,  5,  0, 12,  7]
        , [  1, 15, 13,  8, 10,  3,  7,  4, 12,  5,  6, 11,  0, 14,  9,  2]
        , [  7, 11,  4,  1,  9, 12, 14,  2,  0,  6, 10, 13, 15,  3,  5,  8]
        , [  2,  1, 14,  7,  4, 10,  8, 13, 15, 12,  9,  0,  3,  5,  6, 11]
        ]];
        let i = ((block & 0x20) >> 4 | (block & 1)) as usize;
        let j = ((block & 0x1E) >> 1) as usize;
        unsafe { *TABLES.get_unchecked(box_id).get_unchecked(i).get_unchecked(j) }
        //TABLES[box_id][i][j]
}

#[cfg(test)]
mod bench {
    use test::{Bencher, black_box};

    use super::s;

    #[bench]
    fn bench_s(bencher: &mut Bencher) {
        bencher.iter(|| {
            let box_id = black_box(7);
            (0 .. 40_000_000).fold(0, |acc, block| acc + s(box_id, block))
        });
    }
}

我第一次使用[]运行此基准测试时，花费的时间少于使用get_unchecked()的版本（即使get_unchecked()版本平均速度稍快一点）。 我不确定它是否真的反映了我的真实基准（包括加密大文件），但它提供了一个想法。

我检查了程序集，以确保编译器没有优化绑定检查。

以下是get_unchecked()的版本：

0000000000009360 <_ZN3des7s_table17hbabdd9dee72331a5E>:
    9360:   48 89 f0                mov    %rsi,%rax
    9363:   48 c1 e8 04             shr    $0x4,%rax
    9367:   83 e0 02                and    $0x2,%eax
    936a:   89 f1                   mov    %esi,%ecx
    936c:   83 e1 01                and    $0x1,%ecx
    936f:   48 09 c1                or     %rax,%rcx
    9372:   48 c1 e7 09             shl    $0x9,%rdi
    9376:   48 8d 05 93 57 04 00    lea    0x45793(%rip),%rax        # 4eb10 <ref10404>
    937d:   48 01 f8                add    %rdi,%rax
    9380:   48 c1 e1 07             shl    $0x7,%rcx
    9384:   48 01 c1                add    %rax,%rcx
    9387:   83 e6 1e                and    $0x1e,%esi
    938a:   48 8b 04 b1             mov    (%rcx,%rsi,4),%rax
    938e:   c3                      retq   
    938f:   90                      nop

以下是[]的版本：

0000000000009390 <_ZN3des7s_table17hbabdd9dee72331a5E>:
    9390:   50                      push   %rax
    9391:   48 89 f8                mov    %rdi,%rax
    9394:   48 83 f8 07             cmp    $0x7,%rax
    9398:   77 30                   ja     93ca <_ZN3des7s_table17hbabdd9dee72331a5E+0x3a>
    939a:   48 89 f1                mov    %rsi,%rcx
    939d:   48 c1 e9 04             shr    $0x4,%rcx
    93a1:   83 e1 02                and    $0x2,%ecx
    93a4:   89 f2                   mov    %esi,%edx
    93a6:   83 e2 01                and    $0x1,%edx
    93a9:   48 09 ca                or     %rcx,%rdx
    93ac:   48 c1 e0 09             shl    $0x9,%rax
    93b0:   48 8d 0d 99 57 04 00    lea    0x45799(%rip),%rcx        # 4eb50 <const10401>
    93b7:   48 01 c1                add    %rax,%rcx
    93ba:   48 c1 e2 07             shl    $0x7,%rdx
    93be:   48 01 ca                add    %rcx,%rdx
    93c1:   83 e6 1e                and    $0x1e,%esi
    93c4:   48 8b 04 b2             mov    (%rdx,%rsi,4),%rax
    93c8:   59                      pop    %rcx
    93c9:   c3                      retq   
    93ca:   48 8d 3d b7 a3 25 00    lea    0x25a3b7(%rip),%rdi        # 263788 <panic_bounds_check_loc10404>
    93d1:   ba 08 00 00 00          mov    $0x8,%edx
    93d6:   48 89 c6                mov    %rax,%rsi
    93d9:   e8 82 25 04 00          callq  4b960 <_ZN4core9panicking18panic_bounds_check17hb2d969c3cc11ed08E>
    93de:   66 90                   xchg   %ax,%ax

我们可以看到get_unchecked()版本较小，而[]版本检查边界。

两个版本都以发布模式编译。

为什么get_unchecked()版本不比这快？ 我认为当[] / get_unchecked()被称为48亿次时，它应该比[]版本快至少几秒钟。

修改：我使用valgrind分析了代码。

带有[]的版本显示带有数组索引的行的成本为10，而带有get_unchecked()的版本显示的成本低于1（请参见下图）。 但是，该功能的成本（见图像左侧）保持不变。这很奇怪。有人有解释吗？

版本为get_unchecked()。

版本为[]

Answer 1

我还没有学到很多Rust（但是），但我想我仍然可以回答这部分的表现。

首先，您确定您的基准测试实际上是在运行该功能的独立版本吗？它可能会将函数内联到调用站点，其中box_id是编译时常量。除了去除次要调用/ ret开销之外，表指数计算asm将被显着简化。此外，如果在编译时知道它们未被超过，则可以省略边界检查。

如果有人展示如何修改OP的示例以编译为实际的asm on the Godbolt compiler explorer，我可以看一看并说出更多内容。将它按原样放在godbolt上会产生一些编译为空asm输出的东西。我可能决定学习足够的Rust来自己做，但可能不会很快。

查看该功能的独立版本：

选中版本中的额外说明只是前4：

9390:   50                      push   %rax        # align the stack in case we make a function call (wasted work for the common case)
9391:   48 89 f8                mov    %rdi,%rax   # compiler is dumb, could have checked the value in %rdi
9394:   48 83 f8 07             cmp    $0x7,%rax
9398:   77 30                   ja     93ca <_ZN3des7s_table17hbabdd9dee72331a5E+0x3a>

最后pop %rcx将8添加到％rsp。

因此在函数开始时有4个uop。 （Core2Duo不能在64位模式下进行宏熔丝。虽然Core2Duo可以在32位代码中对cmp / ja进行宏熔合。（参见Agner Fog's microarch pdf）。如果编译器更智能，它只会通过函数（cmp / ja）的快速路径上共有2个额外指令/ uop，而另一个函数调用的堆栈对齐仅在实际进行调用的分支中完成。

你可能会认为将这4个uop问题作为函数的第一个组会出问题，因为它会延迟CPU进入关键路径上的指令。但事实并非如此，因为显然你的代码并没有成为前端的瓶颈。 （你没有显示在循环中调用它的代码的asm）。因此，指令在实际执行的指令之前发布到无序核心。

可能在％rdi中准备好函数输入时，调度程序已经有等待它的关键路径指令。如果基准测试实际上运行的是独立版本，则函数开头的4条额外指令实际上并不会延迟关键路径。因此，关键路径可能是延迟而非吞吐量的瓶颈。 （一次调用的输出是否构成下一次查找的索引？如果是这样，这将阻止函数的多次调用同时针对不同的输入执行.L1负载使用延迟在Core 2上是3个周期（根据Agner Fog's microarch pdf）。

但是，从输入计算表索引的指令中有相当多的指令级并行性。有几个mov指令可以复制，然后说明会对副本和原始文件执行不同的操作。两个args已经分开了。我认为在输入准备就绪和表索引准备就绪之间很多时候并行运行3条指令可能就足够并行了。因此，如果在另一个输入之前执行必须等待3个周期进行表查找，那么额外的uops运行的时间就是这样。 （调度程序首先运行uops，但不是关键路径优先，因此您希望它们有时会延长资源冲突的关键路径（从关键路径窃取执行端口）。 / p>

TL：DR如果一个呼叫的输出是下一个呼叫的输入，则L1负载使用延迟仍然可能很容易成为瓶颈，而不是uop吞吐量。否则，必须有一些其他的瓶颈，使5个额外的uops时间运行，而不会延迟＆＃34;真正的工作＆＃34;。否则，检查将在实际运行的代码中进行优化。