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 tfn 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)
Bu 1 baytlık bayt mı? İplik yapan ipliklerin tepesinin, girişe göre yavaşlamaya neden olduğunu hayal edebiliyorum. –
“Vec” yerine '& [u8]' ve '& [u64]' yi kullanmak daha kolay olurdu. –