Enable asm for OpenSSL

[Denis Kovalchuk]

Hi!

I am wondering if there are any reasons to build OpenSSL with the

'-no-asm' [1][2] option?

Below are the results of synthetic benchmarks for Subversion, depending on

whether OpenSSL is built with or without asm support:

1) OpenSSL is built with the ‘-no-asm’ option.

svnbench null-export https://localhost/svn/iso/~7GB.iso

0 directories

1 files

7,395,016,704 bytes in files

0 properties

0 bytes in properties

50.812102 seconds taken

7,404,963,366 bytes transferred over network

2) OpenSSL is built without the ‘-no-asm’ option.

svnbench null-export https://localhost/svn/iso/~7GB.iso

0 directories

1 files

7,395,016,704 bytes in files

0 properties

0 bytes in properties

17.406729 seconds taken

7,404,963,353 bytes transferred over network

This ~3x improvement is well observed when dealing with localhost, where the

network bandwidth is high enough.

So I would like to suggest enabling asm support for OpenSSL, unless of course
there is a reason to build OpenSSL with the '--no-asm' option. Note that this
change requires NASM [3] to build TortoiseSVN.

[1] https://github.com/stefankueng/TortoiseSVN/blob/cb7495c3ef52b5e86f5c2a41173df44ea20f7841/ext/build/OpenSSL.build#L55

[2] https://wiki.openssl.org/index.php/Compilation_and_Installation#Configure_Options

[3] https://www.nasm.us

Best Regards,

Denis Kovalchuk

[Daniel Sahlberg]

Very interesting results. Did you run this on a build from /trunk/ - ie with OpenSSL 3.1?

The no-asm seems to be added in r18542 (2010-02-06), with the comment "Update to OpenSSL 1.0.0 beta 5". I've searched the mailing lists (https://svn.haxx.se/tsvn/) and couldn't find a motivation why no-asm was required. 

The OpenSSL INSTALL.md notes:

[[[

### no-asm

Do not use assembler code.

This should be viewed as debugging/troubleshooting option rather than for
production use.  On some platforms a small amount of assembler code may still
be used even with this option.

]]]

So I would like to suggest enabling asm support for OpenSSL, unless of course
there is a reason to build OpenSSL with the '--no-asm' option. Note that this
change requires NASM [3] to build TortoiseSVN.

Considering the OpenSSL documentation suggest that no-asm is a debug-ish option, I'm +0 for removing it.

I didn't try to build it yet, but I will do this as time permits.

I'd like to note that we need to get NASM installed on the nightly-build machines.

Kind regards,

Daniel Sahlberg

[Stefan]

The reason for the no-asm option was that the asm code often (it felt like every other release) was broken. Either with the asm that comes with VS, or later with MASM as well: When they switched to requiring MASM I thought the build problems were solved, but the second version after the switch failed again.

So I had enough and used the no-asm switch.

Yes, the asm code is a little bit faster. But honestly the slightly reduced data throughput won't affect 99.99% of all users. Because even in your test with a 7GB file it 'only' took 50 instead of 17 seconds. And who has such files in an svn repository? Scale that test down to a size that might be used in a real setup, and you won't see a user-noticeable difference. Also, your test uses localhost, with a transfer rate of 425MByte/s - so not something you get even on very fast company LAN's.

So for me, I'd rather keep using the no-asm flag.

What bothers me more than using no-asm is that there's even such a switch available! While asm code could be necessary in certain situations for performance, it really is not necessary anymore today, at least not if the devs understand C/C++. Other libs that used asm code before got rid of that (or deprecated the asm code) in newer versions. For example zlib.

So why is openssl still using asm code?

So basically, I won't object if someone wants to enable the asm code in the build. But I myself won't do it.

 

[Denis Kovalchuk]

> Very interesting results. Did you run this on a build from /trunk/ -
> ie with OpenSSL 3.1?

Yes, these results were from trunk with OpenSSL 3.1. However, I believe that
they should be similar with OpenSSL 1.1.x as well.

> The reason for the no-asm option was that the asm code often (it felt like
> every other release) was broken. Either with the asm that comes with VS,
> or later with MASM as well: When they switched to requiring MASM I thought
> the build problems were solved, but the second version after the switch
> failed again.
>
> So I had enough and used the no-asm switch.

Let me try to summarize and list a few more reasons on why I think that
switching to the default OpenSSL build could be beneficial for the project:

1. The improvement comes from using AES-NI instructions for HTTPS.

So this should reduce the CPU usage for all network operations. Perhaps, it
could be especially visible on low-tier hardware.

2. Spending less CPU on common operations means more laptop battery time
and more CPU available for other tasks, in all setups.

For example, here are a couple of additional benchmarks performed over
typical 1Gb LAN that illustrate the overall CPU time reduction:

    Null-export of Subversion root dir, 1Gb LAN:
        CPU time: 130 sec 🠒 8 sec (16x less CPU used)
        Total time: 175 sec 🠒 175 sec
        Avg CPU load: 74% 🠒 4%

    Null-export of .iso file, 1Gb LAN:
        CPU time: 13 sec 🠒 1 sec (13x less CPU used)
        Total time: 63 sec 🠒 63 sec
        Avg CPU load: 20% 🠒 2%

3. Building OpenSSL with assembler support is the current default.

Multiple known projects such as Node.js seem to use and regularly test this
configuration on different platforms and provide additional test coverage.
Compared to that, I think that the `no-asm` build falls into the group of
non-standard configurations (maybe even not intended for production use),
and therefore it could be far less tested in practice.

4. Perhaps you are right about the real setups/throughput, but SVN is good
at handling large files and so there might be users that have multi-terabyte
repositories containing assets and other large binaries.

If these users work through 10GbE (which maybe isn't too uncommon
nowadays), they'll get a significant speedup for their regular operations.

Best Regards,
Denis Kovalchuk

[Daniel Sahlberg]

torsdag 1 juni 2023 kl. 20:11:11 UTC+2 skrev Denis Kovalchuk:

> Very interesting results. Did you run this on a build from /trunk/ -
> ie with OpenSSL 3.1?

Yes, these results were from trunk with OpenSSL 3.1. However, I believe that
they should be similar with OpenSSL 1.1.x as well.

Thanks for confirming.

> The reason for the no-asm option was that the asm code often (it felt like
> every other release) was broken. Either with the asm that comes with VS,
> or later with MASM as well: When they switched to requiring MASM I thought
> the build problems were solved, but the second version after the switch
> failed again.
>
> So I had enough and used the no-asm switch.

Let me try to summarize and list a few more reasons on why I think that
switching to the default OpenSSL build could be beneficial for the project:

1. The improvement comes from using AES-NI instructions for HTTPS.

So this should reduce the CPU usage for all network operations. Perhaps, it
could be especially visible on low-tier hardware.

I doubt there will in average be much gain by handoptimizing ASM code compared to a modern compiler. But if it is required to get access to AES-NI and similar specialized instructions, it make sense.

2. Spending less CPU on common operations means more laptop battery time
and more CPU available for other tasks, in all setups.

For example, here are a couple of additional benchmarks performed over
typical 1Gb LAN that illustrate the overall CPU time reduction:

    Null-export of Subversion root dir, 1Gb LAN:
        CPU time: 130 sec 🠒 8 sec (16x less CPU used)
        Total time: 175 sec 🠒 175 sec
        Avg CPU load: 74% 🠒 4%

    Null-export of .iso file, 1Gb LAN:
        CPU time: 13 sec 🠒 1 sec (13x less CPU used)
        Total time: 63 sec 🠒 63 sec
        Avg CPU load: 20% 🠒 2%

If I understand the figures, the total time doesn't change, ie the CPU is quick enough to decrypt the traffic in either case. But the CPU spends more time idling with the ASM optimized code. (With a faster network, the CPU will of course be the bottleneck).

The improvement on the export of the Subversion root dir is even more impressive.

Power consumption is a valid argument, although I doubt that the power consumption from SVN usage will make a noticeable difference in total battery life - I assume `svn up` (or `svn export`) is a relatively infrequent operation for the average developer. Still, if it doesn't have negative side effects why not use it.

3. Building OpenSSL with assembler support is the current default.

Multiple known projects such as Node.js seem to use and regularly test this
configuration on different platforms and provide additional test coverage.
Compared to that, I think that the `no-asm` build falls into the group of
non-standard configurations (maybe even not intended for production use),
and therefore it could be far less tested in practice.

I agree the no-asm seems to be the less supported option. Quoting again from the OpenSSL INSTALL.md: "This should be viewed as debugging/troubleshooting option rather than for production use."

4. Perhaps you are right about the real setups/throughput, but SVN is good
at handling large files and so there might be users that have multi-terabyte
repositories containing assets and other large binaries.

The large file handling has been a motivation for a recent development of Subversion, the "pristine-less working copy" concept. Yet to be released, but it is part of Subversion /trunk.

To summarize: I'm +0 to removing the no-asm. I'd like to build it myself before upgrading to +1, we also need to figure out a plan to update the nightly build servers so we don't break the nightly builds again. (I believe the nightly builds are provided by a third party, with Stefan being the only one in contact with them).

Kind regards,

Daniel Sahlberg

[Daniel Sahlberg]

I made the following changes and tried building [debug] [|x64|arm64] binaries (ie, 6 combinations in total). There were no build errors and I could successfully test the x86 and x64 versions (no acccess to an arm machine).

[[[

Index: build.txt
===================================================================
--- build.txt   (revision 29575)
+++ build.txt   (working copy)
@@ -33,6 +33,7 @@
                                     https://www.activestate.com/products/perl/
 - WiX 3.10(\b 1)                    http://wixtoolset.org/
 - NAnt 0.92(\b 1)                   http://nant.sourceforge.net
+- NASM 2.16 (or later)              https://nasm.us/

 (\b 1) Add the paths of the binaries to the PATH environment variable. You may have to
     logoff/logon to make the new environment variables take effect!
Index: ext/build/OpenSSL.build
===================================================================
--- ext/build/OpenSSL.build     (revision 29575)
+++ ext/build/OpenSSL.build     (working copy)
@@ -52,7 +52,6 @@
     <exec program="perl" workingdir="${targetDir}">
       <arg value="..\Configure" />
       <arg value="${targetName}" />
-      <arg value="no-asm" />
       <arg value="no-gost" />
       <arg value="no-shared" />
       <arg value="no-autoload-config" />
]]]

Based on Stefan's statement above:

> So basically, I won't object if someone wants to enable the asm code in the build. But I myself won't do it.

I can commit it to trunk. But we need to make sure NASM is installed on the nightly build machine and that Stefan is OK to add use this for the public releases (when the time comes).

Kind regards,

Daniel Sahlberg

[Stefan]

On Saturday, June 3, 2023 at 5:11:53 PM UTC+2 daniel.l...@gmail.com wrote:

=============

--- ext/build/OpenSSL.build     (revision 29575)
+++ ext/build/OpenSSL.build     (working copy)
@@ -52,7 +52,6 @@
     <exec program="perl" workingdir="${targetDir}">
       <arg value="..\Configure" />
       <arg value="${targetName}" />
-      <arg value="no-asm" />
       <arg value="no-gost" />
       <arg value="no-shared" />
       <arg value="no-autoload-config" />
]]]

I can ask Ian to install nasm on the build machine, but I have no idea how long that will take.

Could you maybe add a nant target that enables the asm build and still use no-asm if the nant target was not called? That way the nightly builds would still run through with no-asm. And users who don't have nasm installed can also build without changes.

 

[Daniel Sahlberg]

I can ask Ian to install nasm on the build machine, but I have no idea how long that will take.

Could you maybe add a nant target that enables the asm build and still use no-asm if the nant target was not called? That way the nightly builds would still run through with no-asm. And users who don't have nasm installed can also build without changes.

That is a good idea, although I'd rather prefer to make it asm by default and have a no-asm target since that matches the default in OpenSSL. We can always have the "schedule" target add the no-asm option.

/Daniel 

[Stefan]

good idea, haven't thought of the "schedule" action :)

[Daniel Sahlberg]

lördag 3 juni 2023 kl. 18:48:01 UTC+2 skrev Stefan:

good idea, haven't thought of the "schedule" action :)

Learnt about it from the best in r29552 ;-)

I've tried to come up with something useful in r29579, let's hope I didn't screw up too badly.

/Daniel

[Denis Kovalchuk]

I've tried to come up with something useful in r29579, let's hope I didn't screw up too badly.

 

I've tested the build process with NASM installed/uninstalled on my local
machine and can confirm that it works as advertised. Thank you!

Best Regards,
Denis Kovalchuk