XPost: linux.debian.devel.release   
   From: rob@landley.net   
      
   I note that I've mostly noped out of this discussion because   
   https://mstdn.jp/@landley/115504860540842713 and   
   https://mastodon.sdf.org/@washbear/115646255465589454 but as long as I'm   
   catching up on back email anyway...   
      
   On 11/12/25 12:27, Adrian Bunk wrote:   
   > We are already providing a non-PIE version of the Python interpreter for   
   > users who need it for performance reasons, and it is for example   
   > possible that the benefits of providing packages without hardening (for   
   > situations where hardening is not necessary) might bring larger benefits   
   > than architecture-optimized versions.   
      
   Long ago when I was doing https://landley.net/aboriginal/about.html   
   (work which eventually allowed Alpine to be based on busybox), I benched   
   that statically linking busybox let the autoconf stage of package builds   
   complete about 20% faster under qemu.   
      
   (My theory was lazy binding patched out the PLT indirection on the first   
   call which dirtied the executable page and forced QEMU to discard the   
   native code cache and retranslate it, often multiple times as multiple   
   indirections were dynamically patched. I later found it hilarious that   
   the dynamic linking people went on to do snap and flatpak and so on,   
   using FAR more space for no obvious gain...)   
      
   Does that mean static linking is faster everywhere? Dunno, I haven't   
   tried "everywhere". You can't "optimize" without saying what you're   
   optimizing FOR, and the ground changes out from under you.   
      
   Loop unrolling was an optimization, then became a pessimization when cpu   
   caches showed up, then an optimization again when L2 caches showed up,   
   and the pendulum went back and forth multiple times before I stopped   
   trying to even track it sometime around when branch prediction turned   
   into a security hole and people started doing TLB invalidation   
   mitigations for it. My takeaway lesson was outside of tight inner loops,   
   do the simple thing and let the hardware and optimizers take care of   
   themselves.   
      
   I do know I left the Red Hat world for the Debian world when the new   
   Fedora CD wouldn't install on the Pentium Pro I had at the time (because   
   they'd "moved on" to an architecture newer than the hardware I was still   
   using).   
      
   I had to learn what x86-64-v1 vs v2 were when an android NDK update made   
   all binaries it produced segfault on my netbook. I cared because I was   
   maintaining their command line utilities, and it was nice to be able to   
   actually test that environment. But I didn't discard my hardware to   
   humor the change, I just ran my test binaries under qemu until that   
   netbook died...   
      
   There was talk back then (what, 2018?) about teaching repositories to   
   know about various architecture flags so it could pull optimized   
   packages for your machine, but the discussion petered out because the   
   gains were small and the overhead was huge.   
      
    > Would x32 optimized for v3 be the best option for many use cases?   
      
   It would prevent the x86-64-v2 laptop I'm typing this on from running   
   those binaries, but I've already talked to the netbsd guys and to them   
   running on systems people want to use their stuff on is a point of   
   pride. Like it used to be on Linux, before everybody got old and tired   
   and needed to lighten the load.   
      
   Decisions have costs. It's your call to cull your herd and chastise the   
   outliers, but it usually means some subset will move on to things that   
   are still fun.   
      
   It's an interesting move giving ultimatums to people who never got   
   forced onto windows and never moved to GPLv3. Not "I am stepping down   
   from this and going this way instead", but "xfree86 is now under this   
   new license, you will all comply hey where are you going"...   
      
   *shrug* You do you.   
      
   Rob   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)