[arch-general] makepkg.conf CFLAGS

newer
[arch-general] lxcursor 1.1.14-2...

Yamakaky

1 Jun 2014 1 Jun '14

12:03 p.m.

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

Show replies by date

Martti Kühne

2 Jun 2 Jun

10:58 a.m.

On Sun, Jun 1, 2014 at 2:03 PM, 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

Cross platform compilation is a requirement for the most important of makepkg's users, namely our package maintainers... cheers! mar77i

Daniel Micay

11:11 a.m.

On 02/06/14 06:58 AM, Martti Kühne wrote:

...

On Sun, Jun 1, 2014 at 2:03 PM, 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

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`.

Martti Kühne

11:24 a.m.

On Mon, Jun 2, 2014 at 1:11 PM, Daniel Micay 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

Daniel Micay

12:29 p.m.

On 02/06/14 07:24 AM, Martti Kühne wrote:

...

On Mon, Jun 2, 2014 at 1:11 PM, Daniel Micay 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.

Martti Kühne

12:33 p.m.

On Mon, Jun 2, 2014 at 2:29 PM, Daniel Micay 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

Yamakaky

12:56 p.m.

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 ?

Martti Kühne

1:05 p.m.

On Mon, Jun 2, 2014 at 2:56 PM, Yamakaky 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

Nowaker

1:31 p.m.

...

...
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

Maarten de Vries

1:44 p.m.

On 2 June 2014 14:56, Yamakaky 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

Rashif Ray Rahman

5:53 p.m.

On 2 June 2014 18:56, Yamakaky 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

Leonid Isaev

6:09 p.m.

On Mon, 2 Jun 2014 23:53:38 +0600 Rashif Ray Rahman wrote:

...

On 2 June 2014 18:56, Yamakaky 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

LoneVVolf

10:58 a.m.

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

Rashif Ray Rahman

11:03 a.m.

On 1 June 2014 18: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) ?

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

3615

Age (days ago)

3616

Last active (days ago)

List overview

Download

13 comments

8 participants

participants (8)

Daniel Micay
Leonid Isaev
LoneVVolf
Maarten de Vries
Martti Kühne
Nowaker
Rashif Ray Rahman
Yamakaky