Re: git: 78457b14dd5a - main - net-p2p/*: revert unjust deprecation of three useful ports
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