2016-04-01 7 views
0

DES şifreleme algoritmasını paralel hale getirerek performans geliştirme konusunda sorun yaşıyorum.Dişli DES, dişli olmayandan daha yavaş

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() 
} 

(bu sandıkların crossbeam ve simple_parallel kullanır ama bunlar kullanmayan çözümler kabul eder)

Maalesef bu uygulama parçacığı olmadan sürümden daha yavaştır:

İşte

benim girişimi t
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 
} 

Ben sorunlardır collect ve concat inanıyoruz ama nasıl bilmiyorum Güvenli olmayan kod kullanmadan bunları önlemek.

Bu algoritmanın performansını (kod kullanarak) güvenli kod kullanarak nasıl geliştirebilirim? (Güvenli olmayan kod içeren çözümler de ilginç olabilir, ancak güvenli olmayan kod olmadan bir çözüm bulunması gerektiğine inanıyorum)

+0

Bu 1 baytlık bayt mı? İplik yapan ipliklerin tepesinin, girişe göre yavaşlamaya neden olduğunu hayal edebiliyorum. –

+0

“Vec” yerine '& [u8]' ve '& [u64]' yi kullanmak daha kolay olurdu. –

cevap

4

Bir profil oluşturucu kullanın. Yavaşlamanın nerede olduğunu tahmin etmeyi deneyebilirsiniz, ancak yine de doğru yerde bulamayabilirsiniz.

Ancak, eğitimli bir tahmin için ... mesajı THREAD_COUNT parçalarına bölmeyi ve bu parçaları bunun yerine iş parçacığı havuzuna göndermeyi deneyeceğim. 8 baytlık parçaları ayrı ayrı gönderiyorsanız, bunu DES'in kendisinden daha fazla zaman harcayacaksınız.

+0

Cevabınız için teşekkürler. Haklıydın: Mesajı bölmek zorundaydım. Uygulamayı profillemek için “valgrind” yi denedim, ancak sadece çoğu zaman iş parçacığının kapanmasında harcadığını söylüyor: çözümünüzü böyle bir profil sonucundan nasıl tahmin edebilirim? – antoyo

+0

İlginç ... Henüz paslanmayan profillere bakmadım. Sadece listelenen kapanışı alırsanız, toplamaz, vb. Bu kendi başına iyi bir soru olabilir. İdeal olarak hat başına profil burada yararlı olacaktır. – viraptor

+0

viraptor: Hata ayıklama sembolleri ile derlenmemiştim. Onlarla, daha fazla işlev çağrısı görüyorum, ancak hala bu sorunun nasıl tahmin edileceğinden emin değilim. İki “valgrind” çıktısı arasında gördüğüm fark edilen bir fark, kapağın ilk versiyonumla çok fazla zamanın çağrılmasıdır. Sanırım bu çok fazla iş parçacığının kullanıldığını söylemenin yolu, değil mi? Teşekkürler. – antoyo