Question

我无法通过并行化DES加密算法来提高性能。

这是我的尝试：

fn des(message: &[u8], subkeys: Vec<u64>) -> Vec<u8> {
    let mut pool = Pool::new(THREAD_COUNT);
    let message = message_to_u64s(message);

    crossbeam::scope(|scope| {
        pool.map(scope, message.iter().enumerate(), |(i, &block)| {
            let permuted = ip(block);
            let mut li = permuted & 0xFFFFFFFF00000000;
            let mut ri = permuted << 32;

            for subkey in &subkeys {
                let last_li = li;
                li = ri;
                ri = last_li ^ feistel(ri, *subkey);
            }

            let r16l16 = ri | (li >> 32);
            to_u8_vec(fp(r16l16))
        }).collect::<Vec<_>>()
    }).concat()
}

（这会使用包crossbeam和simple_parallel，但我会接受不使用这些的解决方案）

不幸的是，这个实现比没有线程的版本慢：

fn des(message: &[u8], subkeys: Vec<u64>) -> Vec<u8> {
    let message = message_to_u64s(message);

    let mut cipher = vec![];

    for block in message {
        let permuted = ip(block);
        let mut li = permuted & 0xFFFFFFFF00000000;
        let mut ri = permuted << 32;

        for subkey in &subkeys {
            let last_li = li;
            li = ri;
            ri = last_li ^ feistel(ri, *subkey);
        }

        let r16l16 = ri | (li >> 32);
        let mut bytes = to_u8_vec(fp(r16l16));
        cipher.append(&mut bytes);
    }

    cipher
}

我认为collect和concat是问题，但我不知道如何在不使用不安全代码的情况下避免使用它们。

那么如何使用安全代码提高此算法的性能（通过使用线程）？（带有不安全代码的解决方案也很有趣，但我相信必须有一个没有不安全代码的解决方案）

Answer 1

使用分析器。您可以尝试猜测减速的位置，但无论如何您可能找不到合适的位置。

但是对于一个有根据的猜测......我尝试将消息拆分为THREAD_COUNT部分，然后将这些部分提供给线程池。如果您分别发送8字节片段，那么您将花费更多时间来管理这些片段而不是DES本身。

线程DES慢于非线程

1 个答案: