3 ms·
As a novice Linux (Ubuntu) user, I am curious as to how these new changes for rand will speed up a Linux distro overall or if there is even a way to measure thi
by stefanpie 5y ago
As a novice Linux (Ubuntu) user, I am curious as to how these new changes for rand will speed up a Linux distro overall or if there is even a way to measure this. It seems that, in addition to an overdue replacement SHA-1, the new code is a significant increase in performance. I would think that there are a lot of places where random used in the OS and this update would translate into performance improves in those other places. I'm not an expert and would love to head any thoughts on this.
- loeg 5y ago> As a novice Linux (Ubuntu) user, I am curious as to how these new changes for rand will speed up a Linux distro overall Totally negligible. It speeds up benchmarks of getrandom() and /dev/urandom, which is a good thing, but if you were spending any significant CPU there, it was due to an architectural problem that this doesn't solve. > It seems that, in addition to an overdue replacement SHA-1, the new code is a significant increase in performance. No, the big improvement is removing RDRAND (arch_get_random_long) from the hot path, which only existed on relatively fast x86 hardware. (The only other arch with a non-empty arch_get_random_long implementation was s390, a mainframe.) SHA1 to Blake is only used periodically (~0.003 Hz) and probably not noticeable.
- Genbox 5y agoEncrypted file systems wants to have a word with you. :) I don't think it is hard to imagine an increase in throughput for disk encryption due to less time spent in the RNG.
- loeg 5y agoI don’t believe this will make any appreciable difference for encrypted filesystems. AFAIK the popular scheme (XTS) does not heavily use the RNG.