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
--
You received this message because you are subscribed to the Google Groups
"TortoiseSVN-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/tortoisesvn-dev/d7617d8d-6a18-4e16-8a3d-45d989a5792fn%40googlegroups.com.
