"Optimized Software" in DietPi - questions & discussion

General Discussion
1

Hello, I’m relatively new to DietPi and new to this community. Not sure if this belongs under “General Discussion” or rather under “Requests”, imo the following is a bit of both…

First of all, I must say that I like the idea behind DietPi very much! Whether SBCs, a PC or an Android device - personally I hate when my system is cluttered with nonsense stuff I’ve neither needed nor chosen, even worse when it drains any kind of resources like performance power of my device, who actually doesn’t?

Although there is an aspect I do not really understand: The “optimized software” thing of DietPi.

As far as I understand, the “optimization” of certain software packages is currently limited to the configuration files only. Optimized config files can make (and surely they do!) some noticeable difference, even regardless of the OS one is using. But wouldn’t it be much more optimization of certain software, if it would be compiled device-specific (respectively cross-compiled although I’m not sure about that) for certain devices or if they share f.e. the same CPU/GPU-chip, device-families (like RaspberryPi 2-4 + Zero 2; RaspberryPi 5 separately)?

For example if a certain package (with libraries and executables f.e. coded in C/C++, i.e. something that isn’t just “compiled” into byte code like libs or executables written in Python or Java, not mentioning all the script-based ones ) contained in the DietPi image for f.e. RaspberryPi 5 (which has a CPU afaik different from the previous models, not even mentioning other ARM boards like BananaPi, OrangePi, etc.) would be (re-)compiled on it (or cross-compiled for it’s CPU, if that’s possible and would yield approx. the same results)? Wouldn’t it give it some noticeable boost in performance? Or at least the kernel & indispensable parts that run in userspace while performing critical tasks like systemd and so on?
Or would the improvement gain be more of a theoretical than practical kind i.e. barely noticeable? I understand that also due to the steadily growing list of supported devices it would increase the effort enormously.

But still, I’d like to know at least for myself - would the CPU-/device-specific re-compilation get any yield in performance, thus be an (additional) optimization on machine level or would it get only marginal optimization not profitable compared to the increased effort and work associated with the device-specific recompilation?

It would be cool if we could have some discussion here or so, because I’m sure that there are more than few experts in this community which may give everyone some advice regarding this topic! :slight_smile:

Thanks in advance to everybody for any helpful comments, hints and support regarding this topic!

2

Good question, and it comes up from time to time. The short answer: “optimised software” in DietPi doesn’t mean binaries compiled per board. It means software that is ready to use and correctly integrated into the system.

Where the binaries come from

DietPi doesn’t maintain its own build of the 200+ software titles. Applications come from:

  • Debian repositories: the largest share, e.g. web servers, databases, Samba, desktops and many libraries.
  • Upstream GitHub releases: the second largest source. Many projects (e.g. the *arr apps, Navidrome, Syncthing, Gitea, Vaultwarden’s web vault, many Go/Rust tools) publish ready-made binaries per architecture on GitHub. dietpi-software looks up the latest release, picks the archive matching your architecture and installs it.
  • Vendor APT repositories and language package managers: e.g. Docker, Jellyfin, Node.js, plus pip/npm for Python and Node.js applications like Home Assistant.
  • A handful of packages we build ourselves on GitHub Actions, where nothing suitable is available upstream (e.g. Amiberry, Shairport Sync, Squeezelite, Unbound).

In all cases binaries are built per architecture (armv6l, armv7l, aarch64, x86_64, riscv64), never per board or SoC, whether by Debian, by the upstream developers or by us. That’s the level that actually matters: whether a binary is arm64, armhf or amd64 decides if it runs at all. Whether it was tuned for a Cortex-A76 or a Cortex-A53 doesn’t. For the GitHub releases we don’t compile anything ourselves. We use exactly what the developers publish.

Would per-SoC compilation bring a noticeable gain?

For the vast majority of software: no, or only within measurement noise. A few reasons:

  • Most server software (web servers, databases, media servers, DNS, file sharing…) on an SBC is limited by I/O, meaning storage, network and RAM. It’s rarely limited by raw CPU instruction efficiency.
  • Code that really benefits from specific CPU features (video codecs, crypto, compression, math libraries) usually already picks the best code path at runtime. ffmpeg, OpenSSL and similar libraries detect NEON, AES, SHA and other extensions and use hand-optimised routines regardless of the generic compile target.
  • Heavy media work goes to hardware decoders/encoders (V4L2, VA-API, etc.) anyway. That’s a matter of drivers and kernel, not compiler flags.
  • Many popular applications are written in Python, Node.js, Java, .NET or PHP, where recompiling the application itself changes nothing.

Distributions like Gentoo have shown for years that -march=native builds can give a few percent in specific benchmarks, but in daily use it’s hardly noticeable. Meanwhile you lose binary compatibility, reproducibility and fast security updates.

Why it isn’t feasible for DietPi anyway

We support dozens of boards and 200+ software titles. Rebuilding, testing and keeping all of that up to date (including every Debian security update and every upstream release) per SoC would multiply the work many times over. That’s far beyond what a small volunteer project can do. Using Debian’s packages and the official upstream releases also means we get security fixes as soon as they are published.

So what is “optimised” about DietPi software?

The value is in the end-to-end automation:

  • Ready to run: one selection in dietpi-software installs the application with its dependencies, creates users, permissions, directories and services, and applies a sensible configuration. No manual setup or reading through docs to get a working instance.
  • Configured for the hardware class: settings like caches, worker counts or memory limits are adjusted to the device’s RAM and CPU core count where it makes sense. So the “optimisation” is in the configuration, as you correctly guessed.
  • Software that works together: DietPi makes sure the titles can run side by side. That covers shared web server/PHP/database stacks, no port conflicts, consistent data locations under /mnt/dietpi_userdata, and dependencies handled for you.
  • Lean base system: a minimal install without unnecessary services and with RAM-friendly defaults (e.g. logging to RAM). That leaves more resources for your applications, which on small SBCs brings more than any compiler flag would.
  • Integrated tools: dietpi-services, dietpi-backup, dietpi-drive_manager, updates via dietpi-update, etc., all aware of the installed software.

So the goal isn’t the last few percent of CPU performance. It’s getting from “fresh image” to “working, well-configured system” quickly and reliably, on any supported device.

If you have a specific application where you see a real performance problem, feel free to open a thread for it. Usually the bottleneck is storage (SD card vs. SSD), network or a configuration setting, and those are the things we can actually improve.