Using gcc -march=native for all packages

Since my CPU has all these features, I think Manjaro programs are not using all of them.
I would like to apply following CPU flags to gcc --march to every packet installed and compiled in my machine.
Is there an env. variable I can put this?


/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/cc1 -E -quiet -v - -march=skylake -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -m
popcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -msgx -mbmi2 -mno-pconfig -mno-wbnoinvd -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrtm -mhle -mrdrnd -mf16c -mfsgsbase
-mrdseed -mprfchw -madx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mclflushopt -mxsavec -mxsaves -mno-avx512dq -mno-avx512b
w -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mno-mwaitx -mno-clzero -mno-pku -mno-rdpid -mno-gfni -mno-shstk -mno-avx512vbmi2 -mn
o-avx512vnni -mno-vaes -mno-vpclmulqdq -mno-avx512bitalg -mno-avx512vpopcntdq -mno-movdiri -mno-movdir64b -mno-waitpkg -mno-cldemote -mno-ptwrite -mno-avx512bf16 -mno-enqcmd -mno-
avx512vp2intersect --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=12288 -mtune=skylake

If you want to compile every package yourself, use Gentoo.:stuck_out_tongue_winking_eye:

See https://wiki.archlinux.org/index.php/Makepkg#Building_optimized_binaries

1 Like

Welcome to the forum! :slight_smile:

I’m afraid you misunderstand things. --march=native is a compile-time option, whereby gcc will attempt to make its object code use all of the native CPU flags ─ even though gcc does behave quite conservatively in that regard and may skip a few of those flags. In other words, these are not flags that you can switch on and off at runtime. Once the binary has been built, it has been built.

That said, Manjaro, like Arch, uses generic compile flags because it has to be able to run on all existing x86-64 processors, but there are effectively also processor-specific optimizations compiled into the kernel for the two most common x86-64 platforms, namely the ones from Intel and the ones from AMD. As the matter of fact, the kernel also has support for running paravirtualized on the Xen hypervisor.

At boot time, the kernel will autodetect what processor it’s running on ─ or whether it’s running as a Xen dom0, or as a Xen domU ─ and will select the proper optimizations. Still, these optimizations are only a small subset of the processor-specific CPU flags. On the other hand, there are also several CPU flags that are common between Intel and AMD, and of course, the compiler will make use of those, not just for the kernel but also for userland software.

All things considered, with the processing power of today’s CPUs, optimizing all of the software in the system for the specific CPU in your system will indeed yield a performance benefit, but it won’t be a very large one anymore. And Arch-based distributions such as Manjaro already optimize things to a far greater degree than other distributions do ─ which is one of the reasons why Arch and its various derivatives always perform just a little bit better and run a little leaner in terms of memory consumption.

Thus far the explanation. But as @Yochanan said, if you really do want to have all of your software optimized for your hardware, then you’re going to have to build it all from source code on your local machine, either with a distribution such as Gentoo, Funtoo or Exherbo, or something even more esoteric like SourceMage, or by following the “Linux From Scratch” book and building everything by hand ─ some of which must be built as statically linked first and then rebuilt as dynamically linked afterwards.

And then you do have full control over the CPU flags and other compile-time optimizations. But then you won’t actually be using your computer all that much, because it’ll be too busy burning up CPU cycles for compiling. If you’ve ever built a Firefox version from the source code in the AUR, then you’ll know what I mean. And then we’re not even talking about glibc yet. :wink:

4 Likes

Awesome.
What would it take to build my own Manjaro ISO?
Are there any build scripts for the whole distro?

I already have a build machine for building my Yocto based projects. I could use the same build machine to build Manjaro Distro with custom build gcc flags.

See Build Manjaro ISOs with buildiso - Manjaro

The packages are already built, most by Arch maintainers. If you want to build each and every package yourself, you’d have to download each PKGBUILD and use makepkg. Then you’d want to keep your packages in your own local repo.

That sounds like way too much work for too little benefit. Why spend three hours building a program to save three milliseconds launching it?

Relevant xkcd

image

2 Likes

Awesome.
I think with these (1) instructions I will build my custom binaries and then with (2) instructions I will build the ISO, right?

(1) - wiki.________/index.php/Buildiso_with_AUR_packages:_Using_buildpkg

(2) - wiki.________/index.php/Build_Manjaro_ISOs_with_buildiso

PS - my build machine works like 30 minutes everyday, usually is triggered by webhooks when someone checks in new code. For the other 23 hours and 30 minutes it could do something useful like build Manjaro to my taste.