[arch-general] makepkg.conf CFLAGS
Hi I just discovered the gcc option march=native. It enables all the local-supported optimizations, without downsides except the non-portability of the binaries. Is there a reason why it isn't enabled by default, as cross platform compilation isn't used by most of the users (I think) ? Yamakaky
On Sun, Jun 1, 2014 at 2:03 PM, Yamakaky <yamakaky@yamaworld.fr> wrote:
Hi
I just discovered the gcc option march=native. It enables all the local-supported optimizations, without downsides except the non-portability of the binaries. Is there a reason why it isn't enabled by default, as cross platform compilation isn't used by most of the users (I think) ?
Yamakaky
Cross platform compilation is a requirement for the most important of makepkg's users, namely our package maintainers... cheers! mar77i
On 02/06/14 06:58 AM, Martti Kühne wrote:
On Sun, Jun 1, 2014 at 2:03 PM, Yamakaky <yamakaky@yamaworld.fr> wrote:
Hi
I just discovered the gcc option march=native. It enables all the local-supported optimizations, without downsides except the non-portability of the binaries. Is there a reason why it isn't enabled by default, as cross platform compilation isn't used by most of the users (I think) ?
Yamakaky
Cross platform compilation is a requirement for the most important of makepkg's users, namely our package maintainers...
cheers! mar77i
The official packages are built in a clean container with the makepkg configuration files in the devtools package. In the past, portability issue would have been a factor. I do think the status quo of having it match the devtools flags is perfectly fine, as it's trivial to replace `-march=x86_64 -mtune=generic` with `-march=native`.
On Mon, Jun 2, 2014 at 1:11 PM, Daniel Micay <danielmicay@gmail.com> wrote:
The official packages are built in a clean container with the makepkg configuration files in the devtools package. In the past, portability issue would have been a factor. I do think the status quo of having it match the devtools flags is perfectly fine, as it's trivial to replace `-march=x86_64 -mtune=generic` with `-march=native`.
That's pretty cool, actually. Thanks for the update. Meanwhile you didn't make clear why don't you side with OP after justifying his point? cheers! mar77i
On 02/06/14 07:24 AM, Martti Kühne wrote:
On Mon, Jun 2, 2014 at 1:11 PM, Daniel Micay <danielmicay@gmail.com> wrote:
The official packages are built in a clean container with the makepkg configuration files in the devtools package. In the past, portability issue would have been a factor. I do think the status quo of having it match the devtools flags is perfectly fine, as it's trivial to replace `-march=x86_64 -mtune=generic` with `-march=native`.
That's pretty cool, actually. Thanks for the update. Meanwhile you didn't make clear why don't you side with OP after justifying his point?
cheers! mar77i
Generating efficient code for the local machine by default makes sense and doesn't get in the way of building truly portable packages with devtools. However, I'm sure there are users who build packages without devtools and then expect it to be portable and changing the default is bound to lead to noise on the bug tracker. Arch is primarily a binary distribution, and anyone rebuilding some set of packages with ABS to eek out a bit of extra performance is aware that the default compiler flags need to be changed. It's not going to make a difference for 99% of Arch users, and for *most* (but not all) packages the performance gain is negligible.
On Mon, Jun 2, 2014 at 2:29 PM, Daniel Micay <danielmicay@gmail.com> wrote:
Generating efficient code for the local machine by default makes sense and doesn't get in the way of building truly portable packages with devtools. However, I'm sure there are users who build packages without devtools and then expect it to be portable and changing the default is bound to lead to noise on the bug tracker.
As much as I would welcome the idea of -march=native too, you do have a point there. Thanks. cheers! mar77i
Grouped answer (french guy here, be indulgent ^^) :
Cross platform compilation is a requirement for the most important of makepkg's users, namely our package maintainers...
I think TU know how to configure makepkg for theirs binary packages to be portables.
user has an ageing AMD FX system and wants to replace that with an intel core i7 system. they don't feel like re-installing, so just transfer the harddrive to the intel system. if they used -march=native everything they build on the AMD FX system will need to be rebuild on the core i7 .
Well, that's a good point, I didn't thought about that ^^ But it's only about rebuilding aur packages, not the binary ones.
I believe when the decision was made it was simply based on the fact that being able to share is worth more for the community than local optimization.
PKGBUILDs and packages from repositories have to be portable, but it's not a requirement for self-build AUR packages. Who shares binary packages from AUR ?
Meanwhile you didn't make clear why don't you side with OP after justifying his point?
Sorry, I don't understand your sentence. What's "OP" ?
anyone rebuilding some set of packages with ABS to eek out a bit of extra performance is aware that the default compiler flags need to be changed
I didn't talk about that, all my point is about AUR building.
I'm sure there are users who build packages without devtools and then expect it to be portable
I think they should read a bit of doc before cross-compiling. I'm aware that it doesn't make a great difference for most packages, for only this portability downside so why private ourselves ?
On Mon, Jun 2, 2014 at 2:56 PM, Yamakaky <yamakaky@yamaworld.fr> wrote:
Grouped answer (french guy here, be indulgent ^^) :
Sure. [...]
Meanwhile you didn't make clear why don't you side with OP after justifying his point?
Google it. OP is the "Original Poster". Also known as "You".
anyone rebuilding some set of packages with ABS to eek out a bit of extra performance is aware that the default compiler flags need to be changed
I didn't talk about that, all my point is about AUR building.
makepkg.conf affects *any* building, not just such from aur. That distinction does nowhere exist.
I'm sure there are users who build packages without devtools and then expect it to be portable
I think they should read a bit of doc before cross-compiling.
It's not crosscompiling if I think "64 bit intel-compatible, aka x86_64", is it? We're discussing running the same binary on similar enough platforms in that they're called by the same name. cheers! mar77i
user has an ageing AMD FX system and wants to replace that with an intel core i7 system. they don't feel like re-installing, so just transfer the harddrive to the intel system. if they used -march=native everything they build on the AMD FX system will need to be rebuild on the core i7 .
Well, that's a good point, I didn't thought about that ^^ But it's only about rebuilding aur packages, not the binary ones.
People use X, GPU drivers and a bunch of other stuff from AUR. -- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu
On 2 June 2014 14:56, Yamakaky <yamakaky@yamaworld.fr> wrote:
PKGBUILDs and packages from repositories have to be portable, but it's not a requirement for self-build AUR packages. Who shares binary packages from AUR ?
I do, in fact. I have a couple of machines, and not all of them have the same processing power or memory capacity, so building on some of them can take very long. I imagine there are more people who do the same. And it could take a lot of debugging until you can nail it down to optimization flags. Regards, Maarten
On 2 June 2014 18:56, Yamakaky <yamakaky@yamaworld.fr> wrote:
I believe when the decision was made it was simply based on the fact that being able to share is worth more for the community than local optimization.
PKGBUILDs and packages from repositories have to be portable, but it's not a requirement for self-build AUR packages. Who shares binary packages from AUR ?
Anybody can share binary packages that they build off of AUR buildscripts -- that is exactly what we allow by making these flags the default. With local optimization, users end up spending time rebuilding. You may build a bunch of packages and decide to share them from a repo, or you may want help from somebody else with runtime problems that you're having. There is no statistical backing here AFAIK, so if you feel strongly about it, you are welcome to approach the pacman developers in order to reach a new conclusion. -- GPG/PGP ID: C0711BF1
On Mon, 2 Jun 2014 23:53:38 +0600 Rashif Ray Rahman <schiv@archlinux.org> wrote:
On 2 June 2014 18:56, Yamakaky <yamakaky@yamaworld.fr> wrote:
I believe when the decision was made it was simply based on the fact that being able to share is worth more for the community than local optimization.
PKGBUILDs and packages from repositories have to be portable, but it's not a requirement for self-build AUR packages. Who shares binary packages from AUR ?
Anybody can share binary packages that they build off of AUR buildscripts -- that is exactly what we allow by making these flags the default.
With local optimization, users end up spending time rebuilding. You may build a bunch of packages and decide to share them from a repo, or you may want help from somebody else with runtime problems that you're having.
There is no statistical backing here AFAIK, so if you feel strongly about it, you are welcome to approach the pacman developers in order to reach a new conclusion.
Remember also that gcc optimization flags make difference only for programs which run in or close to realtime. Examples include lapack/arpack, blender, or your own HPC code. For everything else advanced optimization via -march= and -O? flags yields no measurable performance increase. Even if you build e.g. thunderbird using -O1 for a generic x86_64 machine, you'll not notice any slowdown compared to an "optimized" build (actually, that's how I build all my local packages). Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On 01-06-14 14:03, Yamakaky wrote:
Hi
I just discovered the gcc option march=native. It enables all the local-supported optimizations, without downsides except the non-portability of the binaries. Is there a reason why it isn't enabled by default, as cross platform compilation isn't used by most of the users (I think) ?
Yamakaky
Yamakaky, the non-portability is a very big downside imo. When using -march=native on a core i7, those packages won't run on an amd processor or on an intel atom. They might even give problems on a core i3. All official packages for arch are build on systems running arch. With current makepkg default, all packages build will run on all systems with same architecture (x86-64 / i686) . Now assume makepkg had -march=native as default. packages build for official repos now will fail on all systems that don't have same cpu family. This effectively forces all devs to change makepkg defaults. Incase they forget it, their offficial build will fail. some user-specific examples : user has a netbook with an intel atom processor and needs to compile program foo to work on it. building foo on the netbook takes over an hour. User tries building foo on his main system with a core i7, SSD etc and finds building foo takes only a few minutes there. foo build with makepkg default on the i7 will run flawlessly on the netbook. user has an ageing AMD FX system and wants to replace that with an intel core i7 system. they don't feel like re-installing, so just transfer the harddrive to the intel system. if they used -march=native everything they build on the AMD FX system will need to be rebuild on the core i7 . LW
On 1 June 2014 18:03, Yamakaky <yamakaky@yamaworld.fr> wrote:
Hi
I just discovered the gcc option march=native. It enables all the local-supported optimizations, without downsides except the non-portability of the binaries. Is there a reason why it isn't enabled by default, as cross platform compilation isn't used by most of the users (I think) ?
I think your main concern is why portability would matter first and why we would stick with that by default. I believe when the decision was made it was simply based on the fact that being able to share is worth more for the community than local optimization. -- GPG/PGP ID: C0711BF1
participants (8)
-
Daniel Micay
-
Leonid Isaev
-
LoneVVolf
-
Maarten de Vries
-
Martti Kühne
-
Nowaker
-
Rashif Ray Rahman
-
Yamakaky