On 11/25/2021 10:31 AM, Helge Oldach wrote:
Allan Jude wrote on Thu, 25 Nov 2021 16:09:25 +0100 (CET):
On 11/25/2021 2:38 AM, Helge Oldach wrote:
hmo@p48 ~ $ for f in 0 1 2 3 8 16 32 64 128 ; do echo -n $f:; env OPENSSL_armcap=$f
openssl speed -evp aes-256-gcm 2>&1 | tail -1 | cut -wf7; done
0:42295.15k
1:23891.19k
2:42208.57k
3:23970.56k
8:42354.98k
16:42199.06k
32:size
Illegal instruction (core dumped)
64:42322.42k
128:42275.00k
hmo@p48 ~ $
So I guess HWCAP_FP is the culprit? Maybe related to hard/soft floating
point math which indeed is kind of special on the Pi?
So yeah, the issue seems to be that floating point on the RPi4 is slower
than not, but now openssl (properly) detects that the CPU advertises
support for it.
As seen elsewhere in the thread, most other ARM platforms get a very
significant speed boost.
So can we disable FP within OpenSSL for the RPi by default? This commit
basically introduced a regression for this platform and I think that
should be fixed.
Or it the root cause a suboptimal FP implementation that is not adequate
for the RPi?
Kind regards
Helge
The root cause is that the RPi4 advertises support for FP, but its FP is
slow.
I don't know that there is an easy way to detect the RPi4 specifically.
You might be able to just disable the FP bit by setting
OPENSSL_armcap=~1 globally, or maybe via openssl.conf?
--
Allan Jude
