http://cvs.openssl.org/chngview?cn=22857. For reference, comments refer to "cycles per byte", "saturation factor" and "GBps per socket". ... ... "saturation factor" is obtained by dividing largest block result for 'openssl speed alg -multi X' by result for 'openssl speed alg' and by number of sockets in system.
Just to clarify for public reference. There are 8 cores per physical processor and each of these cores can execute 8 threads. In other words each 8 threads *share* same computational resources. If a code is optimal, then cumulative performance vs. amount of threads curve saturates at 8 (or at 8*N on multi-socket system). Because shared computational resources are fully utilized all the time. If threads consisted of instructions that depend on each other and it took 8 cycles to execute each of those instructions, then curve would saturate at 64. So any number above 8x is indication of how underutilized resources are from single thread viewpoint. Codes in question "saturate" at 11x-12x. There is nothing we can do about it [because single instruction does everything], but to measure it and write it down. But given that "worst case" factor is 64x, 11x-12x is not bad at all.
______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
