Re: git: 78457b14dd5a - main - net-p2p/*: revert unjust deprecation of three useful ports

From: Alexey Dokuchaev <danfe_at_freebsd.org>
Date: Wed, 30 Apr 2025 07:25:59 UTC
On Sat, Apr 05, 2025 at 09:20:52AM +0200, Daniel Engberg wrote:
> On 2025-03-31 01:09, Alexey Dokuchaev wrote:
> > commit 78457b14dd5a11cf343fed3d70e8a5cc09292d8b
> > 
> >    net-p2p/*: revert unjust deprecation of three useful ports
> >    These are written in traditional languages and do not require
> >    complex, resource-consuming bootstrap or runtime, contrary to
> >    the suggested alternatives.
> 
> Upstream did some testing and concluded that it's faster and in some
> cases by quite a bit.
> https://github.com/autobrr/mkbrr?tab=readme-ov-file#performance
> 
> Out of curiosity, how did you evaluate runtime?

FWIW when I got CPU with SHA-1 intrinsics which OpenSSL could make use of
I wanted to benchmark `net-p2p/btcheck' against different SHA-1 providers
(selectable via options) to see how beneficial hardware calculation can
be, but never completed this quest for reasons I can't really recall. :(
Similar test for `net-p2p/mktorrent' port also failed through the cracks.

However, run-time performance differences don't bother me as much as what
language these tools are written and what is required to build them, and
here nothing can beat C code (okay, Pascal, Ada, or OCaml probably can).
From that point, a piece of software written in Rust or even Go can never
be an adequate replacement for a similar program written in a traditional
low-footprint language, because it cannot be built on commodity hardware,
e.g. your typical cheap laptop from a nearby electronics market.  Ideally,
it should be buildable on TI-85 but that's probably a bit too much to ask.

./danfe