3 ms·

>I’ve configured the compiler once to work in an optimized way for my specific CPU, then compiled all the LXDE packages from ABS and installed them. I noticed t

>I’ve configured the compiler once to work in an optimized way for my specific CPU, then compiled all the LXDE packages from ABS and installed them. I noticed they were running a little bit faster after that. I would love to hear about what configuring the compiler to work in an optimized way for your specific CPU entails.

whoopdedo 9y ago
export CC=gcc -march=native
- mac01021 9y ago
  Can you explain? Doesn't "-march=native" just set the target CPU architecture to be that of the host you're running on? Isn't that the default behaviour anyway?
  - tomsmeding 9y ago
    I believe that by default, gcc is somewhat conservative with its target architecture, ignoring a few of the newest features in favour of better cross-system compatibility. With that flag, and possibly -mtune=native, you get the full power of your CPU back.
deleted 9y ago
[deleted]
jcelerier 9y ago
In arch the compile flags are set in /etc/makepkg.conf. Got my system compiled with CFLAGS="-march=native -O3 -flto -pipe -fstack-protector-strong --param=ssp-buffer-size=4" CXXFLAGS="-march=native -O3 -flto -pipe -fstack-protector-strong --param=ssp-buffer-size=4" LDFLAGS="-Wl,-O3,--sort-common,--as-needed,-z,relro,-flto" MAKEFLAGS="-j16"
- mac01021 9y ago
  Interesting. So how does this set of options tend to differ from those used by the guys who build the normal binary packages?
  - giancarlostoro 9y ago
    They probably compile it with generic flags to support x86 or x64 for having more than a handful of package repositories for different architectures, as opposed to having hundreds / thousands of package repositories for every processor released out there. When a package is compiled down to your specific processor it is not guaranteed at all to run on another system. This is also done by people who use Gentoo as well as other source based distributions.
  - jcelerier 9y ago
    Default is CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt" CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt" LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now" which ensure that it would still work with an AMD Athlon64 from 2003, but you don't get any "new" things such as SSE4, AVX, etc. unless the developer hand-codes specific cases for these CPUs.

whoopdedo 9y ago

export CC=gcc -march=native

mac01021 9y ago
Can you explain? Doesn't "-march=native" just set the target CPU architecture to be that of the host you're running on? Isn't that the default behaviour anyway?
- tomsmeding 9y ago
  I believe that by default, gcc is somewhat conservative with its target architecture, ignoring a few of the newest features in favour of better cross-system compatibility. With that flag, and possibly -mtune=native, you get the full power of your CPU back.

deleted 9y ago

[deleted]

jcelerier 9y ago

In arch the compile flags are set in /etc/makepkg.conf. Got my system compiled with CFLAGS="-march=native -O3 -flto -pipe -fstack-protector-strong --param=ssp-buffer-size=4" CXXFLAGS="-march=native -O3 -flto -pipe -fstack-protector-strong --param=ssp-buffer-size=4" LDFLAGS="-Wl,-O3,--sort-common,--as-needed,-z,relro,-flto" MAKEFLAGS="-j16"

mac01021 9y ago
Interesting. So how does this set of options tend to differ from those used by the guys who build the normal binary packages?
- giancarlostoro 9y ago
  They probably compile it with generic flags to support x86 or x64 for having more than a handful of package repositories for different architectures, as opposed to having hundreds / thousands of package repositories for every processor released out there. When a package is compiled down to your specific processor it is not guaranteed at all to run on another system. This is also done by people who use Gentoo as well as other source based distributions.
- jcelerier 9y ago
  Default is CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt" CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt" LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now" which ensure that it would still work with an AMD Athlon64 from 2003, but you don't get any "new" things such as SSE4, AVX, etc. unless the developer hand-codes specific cases for these CPUs.