45
Building from source - disadvantages? (slrpnk.net)
submitted 1 year ago by to c/linux@lemmy.ml
28 comments fedilink hide all child comments
 

Are there any risks or disadvantages to building software from source, compared to installing a package? Can it mess with my system in any way?

I usually avoid it because I've found it to be a faff and often doesn't work anyway but in a couple of cases it has been necessary.

you are viewing a single comment's thread
view the rest of the comments
[–] 12 points 1 year ago (8 children)

Gentoo user here.

Of course I always build every package from source because that's how Gentoo works.

Well, you get well optimized software for your specific cpu and architecture that often will not run on a different CPU. At the cost of lots of time.

For big ones like Firefox or rust I always choose the prebuilt ones... But everything else is from sources.

Also, another great advantage is to customize package features to your likings, like disable an audio backend or enable another, and such.

  • permalink
  • fedilink
  • source
  • hideshow 8 child comments
    •
  • [–] 8 points 1 year ago (5 children)

    The irony is that big things like Firefox can get the most advantages from building for your specific CPU variant, especially if you use them frequently.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 6 points 1 year ago (2 children)

    Yeah, but only when you build with lto+pgo which will take even longer

    https://wiki.gentoo.org/wiki/Project:Mozilla/Firefox_Benchmarks_2025_Q1

    spend an hour building to save 1ms per page load

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 1 year ago (1 child)

    I thought the optimizations didn't actually do they much.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 1 year ago

    They don't in general, but things that do heavily detailed graphics work (like your compositor or browser) or lots of cryptography work on the CPU can get a bit more out of those newer instructions than many other programs.

    Very approximately, things that Gentoo offers prebuilt versions of because compiling them is so resource intensive are often the things that can get the best benefit out of your architecture variant. (Not singling out Gentoo here as an example of "doing it badly" - they do the sensible thing by providing these prebuilt binaries, but in some ways it defeats the purpose of optimised source distributions.)

    It's a Hard Problem™ to solve.

  • permalink
  • fedilink
  • source
  • parent
  • [–] [S] 1 point 1 year ago (1 child)

    you get well optimized software for your specific cpu and architecture

    That's really cool. How does that work?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 4 points 1 year ago*

    All x86_64 CPUs support a certain "base" set of instructions. But most of them also support some additional instruction sets: SIMD (single instruction multiple data - operations on vectors and matrices), crypto (encryption/hashing), virtualization (for running VMs), etc. Each of those instructions replaces dozens or hundreds of "base" instructions, speeding certain specific operations dramatically.

    When compiling source code into binary form (which is basically a bunch of CPU instructions plus extra fluff), you have to choose which instructions to use for certain operations. E.g. if you want to multiply a vector by a matrix (which is a very common operation in like a dozen branches of computer science), you can either do the multiplication one operation at a time (almost as you would when doing it by hand), or just call a single instruction which "just does it" in hardware.

    The problem is "which instruction sets do I use". If you use none, your resulting binary will be dogshit slow (by modern standards). If you use all, it will likely not work at all on most CPUs because very few will support some bizarre instruction set. There are also certain workarounds. The main one is shipping two versions of your code: one which uses the extensions, the other which doesn't; and choosing between them at runtime by detecting whether the CPU supports the extension or not. This doubles your binary size and has other drawbacks too. So, in most cases, it falls on whoever is packaging the software for your distro to choose which instruction sets to use. Typically the packager will try to be conservative so that it runs on most CPUs, at the expense of some slowdown. But when you the user compile the source code yourself, you can just tell the compiler to use whatever instruction sets your CPU supports, to get the fastest possible binary (which might not run on other computers).

    In the past this all was very important because many SIMD extensions weren't as common as they are today, and most distros didn't enable them when compiling. But nowadays the instruction sets on most CPUs are mostly similar with minor exceptions, and so distro packagers enable most of them, and the benefits you get when compiling yourself are minor. Expect a speed improvement in the range of 0%-5%, with 0% being the most common outcome for most software.

    TL;DR it used to matter a lot in the past, today it's not worth bothering unless you are compiling everything anyways for other reasons.

  • permalink
  • fedilink
  • source
  • parent