Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Should I rebuild for the Core i7? If so, is this the way?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Unsupported Software
View previous topic :: View next topic  
Author Message
Fitzcarraldo
Advocate
Advocate


Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom

PostPosted: Wed Sep 07, 2011 11:49 am    Post subject: Should I rebuild for the Core i7? If so, is this the way? Reply with quote

Having recently read this post, I believe I may need to recompile all the packages on my laptop to take full advantage of its Core i7 720QM CPU. Currently I have everything compiled using gcc-4.4.2. The relevant parameters currently specified in my /etc/make.conf are:

Code:
CFLAGS="-O2 -march=native -pipe"
CHOST="x86_64-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"
LDFLAGS="-Wl,-O1,--as-needed"
ACCEPT_KEYWORDS="~amd64"
MAKEOPTS="-s -j4"

This is what using -march=native results in when using gcc-4.4.2 on my laptop:

Code:
$ echo "" | gcc -march=native -v -E - 2>&1 | grep cc1
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.2/cc1 -E -quiet -v - -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf -mpopcnt -msse4.2 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=256 -mtune=core2

QUESTION 1: I assume that the resulting binaries, built with -march=core2, are not optimal for my Core i7 CPU. Would I be correct in thinking that?

QUESTION 2: Does gcc-4.5.* fully support the Core i7 CPU?

If I were to rebuild all the packages, I believe I should follow the Gentoo GCC Upgrade Guide to upgrade from gcc-4.4.2 to gcc-4.5.3-r1, the highest non-masked version in the Portage tree at present. If I read that guide correctly, I would need to do the following:

Code:
# emerge -uav =gcc-4.5.3-r1
# gcc-config x86_64-pc-linux-gnu-4.5.3
# env-update && source /etc/profile
# emerge --oneshot -av libtool
# emerge -eav system
# emerge -eav world
# emerge -aC =sys-devel/gcc-4.4.2

QUESTION 3: Would the above steps be the correct procedure to upgrade from gcc-4.4.2 to gcc-4.5.3-r1? Should I do anything else, or do anything differently?

Any advice would also be appreciated. Thanks in advance for your replies.
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.

Fitzcarraldo's blog
Back to top
View user's profile Send private message
s0be
Apprentice
Apprentice


Joined: 23 Nov 2002
Posts: 240

PostPosted: Wed Sep 07, 2011 1:22 pm    Post subject: Re: Should I rebuild for the Core i7? If so, is this the way Reply with quote

Fitzcarraldo wrote:
Code:
$ echo "" | gcc -march=native -v -E - 2>&1 | grep cc1
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.2/cc1 -E -quiet -v - -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf -mpopcnt -msse4.2 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=256 -mtune=core2


This is with gcc 4.5.3 on my i7 820qm. It looks like the only difference may be the l2 cache size optimization between the versions without forcing stuff.

Code:
s0be@anvil ~ $ echo "" | gcc -march=native -v -E - 2>&1 | grep cc1
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/cc1 -E -quiet -v - -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf -mpopcnt -msse4.2 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=core2


Based on that, I don't see you noticing any difference without going to risky C-Flags (assuming the rest is equal, gcc 4.5 may produce better code than 4.4)
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3509

PostPosted: Wed Sep 07, 2011 1:44 pm    Post subject: Reply with quote

Take another look at the thread you referenced and you'll see several posts of mine there, as well. I'll have to agree with s0be - there probably isn't much call to recompile now. Whenever it's time to upgrade to gcc-4.6, it will recognize the Core-I7 processor properly, instead of seeing it as a Core2, and then it would probably be good to recompile everything.

If you really felt like ricing now, you could come up with a more complex CFLAGS line that individually set specific features. The best way would be to find someone who has already installed gcc-4.6 and get them to run the line Fitzcarraldo suggests, then tuck those differences into your CFLAGS. As an alternative you might want to check out the thread on ~arch gcc-4.6 and look at migrating now.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
Jupiter1TX
Guru
Guru


Joined: 24 Feb 2006
Posts: 546
Location: 3rd Rock

PostPosted: Wed Sep 07, 2011 2:00 pm    Post subject: Reply with quote

I've been using 4.6.1 for about three months now and haven't had any
compile issues, stability or, other weirdness.
Code:
vger ~ # echo "" | gcc -march=native -v -E - 2>&1 | grep cc1
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.1/cc1 -E -quiet -v - -D_FORTIFY_SOURCE=2 -march=corei7 -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm -mno-avx -msse4.2 -msse4.1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=corei7

_________________
Core i7 920 D0 | Asus P6T DLX | Patriot Viper 1600 6GB | Antec Quattro 850W
Geforce 8800GTX OC2 768MB | Dell 22" LCD | Koolance Exos2/Swiftech GTZ
GCC 4.6.1 | 3.7.x-geek | Xorg-7.4-x | KDE-4.7.x | Compiz
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3509

PostPosted: Wed Sep 07, 2011 2:32 pm    Post subject: Reply with quote

Just for jollies, I grabbed all of the flags listed for gcc-4.6 and tried to add them to gcc-4.4.5:
Code:
# echo "" | gcc -march=native -mno-movbe -mno-aes -mno-pclmul -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm -mno-avx -msse4.1 --param l2-cache-size=8192 -v -E - 2>&1 | grep cc1
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.5/cc1 -E -quiet -v - -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf -mpopcnt -msse4.2 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=256 -mtune=core2 -mno-movbe -mno-aes -mno-pclmul -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm -mno-avx -msse4.1
cc1: error: unrecognized command line option "-mno-movbe"
cc1: error: unrecognized command line option "-mno-lwp"
cc1: error: unrecognized command line option "-mno-fma4"
cc1: error: unrecognized command line option "-mno-xop"
cc1: error: unrecognized command line option "-mno-bmi"
cc1: error: unrecognized command line option "-mno-tbm"

Looks like some of the options are just plain newer than gcc-4.4.5, at least.

I also tried tacking the options that would work onto gcc-4.4.5, and it accepted almost everything. Really all it did was get rid of the hate-mail from the first try.
Code:
# echo "" | gcc -march=native -mno-aes -mno-pclmul -mno-abm -mno-fma -mno-avx -msse4.1 --param l2-cache-size=8192 -v -E - 2>&1 | grep cc1  /usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.5/cc1 -E -quiet -v - -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf -mpopcnt -msse4.2 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=256 -mtune=core2 -mno-aes -mno-pclmul -mno-abm -mno-fma -mno-avx -msse4.1


Probably the most annoying thing here is that it didn't recognize the bigger l2 cache size. Another oddity is that the recommended CFLAGS for CoreI7, at least with gcc<4.6, is "-march=core2 -mtune=generic". I'm not sure why they suggested against the Core2 tuning that would have been default. I haven't actually tried any of this, and am not sure that any of it is worth bothering with, without the l2 cache size tuning.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
gringo
Advocate
Advocate


Joined: 27 Apr 2003
Posts: 3793

PostPosted: Wed Sep 07, 2011 3:51 pm    Post subject: Reply with quote

Quote:
Another oddity is that the recommended CFLAGS for CoreI7, at least with gcc<4.6, is "-march=core2 -mtune=generic"


not even the intel guys agreed on which were the best CFLAGS by default for the atoms and the icores before we had specific tunables.

i just switched to gcc-4.6 and this is what it tells me about my i5 M 520 :

Code:
-march=corei7 -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm -mno-avx -msse4.2 -msse4.1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=3072 -mtune=corei7


cheers all
Back to top
View user's profile Send private message
Ormaaj
Guru
Guru


Joined: 28 Jan 2008
Posts: 319

PostPosted: Fri Sep 09, 2011 8:24 pm    Post subject: Reply with quote

For the i7 I'd recommend -march=native with -O3 or at minimum -O2 with -ftree-vectorize. This is completely safe. Nothing I've been able to measure so far benefits from -O2 on this machine. I've no idea why it's recommended for modern hardware. cachegrinding a few of my own things recently usually shows improvements in critical sections.
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7470

PostPosted: Fri Sep 09, 2011 9:41 pm    Post subject: Re: Should I rebuild for the Core i7? If so, is this the way Reply with quote

Fitzcarraldo wrote:

Code:
# emerge -uav =gcc-4.5.3-r1
# gcc-config x86_64-pc-linux-gnu-4.5.3
# env-update && source /etc/profile
# emerge --oneshot -av libtool
# emerge -eav system
# emerge -eav world
# emerge -aC =sys-devel/gcc-4.4.2



build your gcc, build your glibc with it, and rebuild your gcc with that glibc, and build them all with their bin package as safety security
Code:
emerge =gcc-4.5.3-r1 && gcc-config x86_64-pc-linux-gnu-4.5.3 && emerge -u --buildpkg glibc && emerge =gcc-4.5.3-r1 --buildpkg

next fix your library :
Code:
fix_libtool_files.sh 4.4.2

next to that if you want all your system build with that new toolchain just emerge -e world (system is include in world), or you can just stay like that and wait for an update, when updating your software will use that toolchain.

optional but i recommand it:
Get more security by building the needed system tools bin package
Code:
emerge --buildpkgonly -e system


optional but i recommand it:
don't emerge -aC yourpreviousgcc, it won't kill you to kept for a while another gcc version under your hands in case you mistake something with your toolchain, you could switch to that previous version to unstuck from a poor situation easy
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54099
Location: 56N 3W

PostPosted: Fri Sep 09, 2011 10:25 pm    Post subject: Reply with quote

It all depends on what you use your system for.

If its all interactive stuff, you won't notice any difference. You CPU will spend longer waiting for you is all.
With compute intensive applications you may be able to measure the improvement.
Its likely the total rebuild will take longer than any time saved as a result of the rebuild.

Just let nature take its course and let the changes go in with your normal update cycle.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 8933

PostPosted: Fri Sep 09, 2011 11:29 pm    Post subject: Reply with quote

NeddySeagoon wrote:
Just let nature take its course and let the changes go in with your normal update cycle.

+1
Back to top
View user's profile Send private message
Yamakuzure
Advocate
Advocate


Joined: 21 Jun 2006
Posts: 2280
Location: Adendorf, Germany

PostPosted: Tue Sep 13, 2011 12:36 pm    Post subject: Reply with quote

Ormaaj wrote:
For the i7 I'd recommend -march=native with -O3 or at minimum -O2 with -ftree-vectorize. This is completely safe. Nothing I've been able to measure so far benefits from -O2 on this machine. I've no idea why it's recommended for modern hardware. cachegrinding a few of my own things recently usually shows improvements in critical sections.
Before stating something like that again, you might like to take a look at this little experiment: http://sigtrap.wordpress.com/2011/01/04/gcc-optimization-case-study/
Quote:
Compiler flags matter, but like all optimization their usefulness and impact is highly workload and application dependent.

_________________
Important German:
  1. "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
  2. "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
Back to top
View user's profile Send private message
mattst88
Developer
Developer


Joined: 28 Oct 2004
Posts: 422

PostPosted: Thu Sep 15, 2011 10:05 pm    Post subject: Re: Should I rebuild for the Core i7? If so, is this the way Reply with quote

krinn wrote:
build your gcc, build your glibc with it

With you so far.
krinn wrote:
and rebuild your gcc with that glibc

What? Why?
_________________
My Wiki page
Back to top
View user's profile Send private message
Ormaaj
Guru
Guru


Joined: 28 Jan 2008
Posts: 319

PostPosted: Tue Sep 20, 2011 9:34 pm    Post subject: Reply with quote

Yamakuzure wrote:
Ormaaj wrote:
For the i7 I'd recommend -march=native with -O3 or at minimum -O2 with -ftree-vectorize. This is completely safe. Nothing I've been able to measure so far benefits from -O2 on this machine. I've no idea why it's recommended for modern hardware. cachegrinding a few of my own things recently usually shows improvements in critical sections.
Before stating something like that again, you might like to take a look at this little experiment: http://sigtrap.wordpress.com/2011/01/04/gcc-optimization-case-study/
Quote:
Compiler flags matter, but like all optimization their usefulness and impact is highly workload and application dependent.


K so for the first contrived example, O2 and O3 were identical, neither of which includes funroll-loops so the result isn't surprising (O3 with unrolling wasn't tested). The second is so vague I have no idea what he's doing or how he's cherry-picking the results. What he's testing, how he's testing it etc are never mentioned. O2 performed better by a whopping 3.8%. For the third, O2 performed marginally better (half the time) but as the one commenter points out, this likely has to do with hyper-threading which I've noticed as a variable in my own tests as well. Usually when benchmarking I would have explicitly run with schedtool locking the affinity to the correct virtual processor pairs. He probably would have seen O3 come out ahead all the time if this detail wasn't screwed up.

And anyway I'm not arguing that corner cases and exceptions don't exist especially in micro-benchmarks. However I am confident that O3 is a better starting point and default at least for Gentoo purposes on this type of hardware. If performance issues are found they should be dealt with on a whitelist rather than blacklist basis (This was the rationale behind creating an -Ofast option actually as there's a significant amount of software out there missing out on low-hanging fruit because the build doesn't bother with floating point optimization where possible). If you're going to go O2 I would modify it heavily as there are certain options missing which I can't imagine you would ever not want for a final non-debug build.

Also it goes without saying that I'm speaking purely from a performance standpoint without regard for security/stability/reliability.
Back to top
View user's profile Send private message
deanpence
Apprentice
Apprentice


Joined: 08 Nov 2004
Posts: 158
Location: Earth

PostPosted: Tue Oct 04, 2011 6:23 am    Post subject: Re: Should I rebuild for the Core i7? If so, is this the way Reply with quote

mattst88 wrote:
krinn wrote:
build your gcc, build your glibc with it

With you so far.
krinn wrote:
and rebuild your gcc with that glibc

What? Why?


From what I remember of my "Linux From Scratch" days, this is just a method of bootstrapping gcc. To be sure there are no binary incompatibilities in the toolchain, you first cross-compile binutils, then gcc, then glibc, all of which you then use to build a new toolchain. If I saw a need to do this, which I don't unless there are known issues/incompatibilities, here's how I would probably do an upgrade (i.e., no need to cross-compile for an actual bootstrap, no new versions of glibc or binutils—only gcc):

Code:
# # DON'T DO THIS. IT'S SILLY.
# emerge -vq =gcc-<NEW GCC VERSION> \
  && gcc-config $(portageq envvar CHOST)-<NEW GCC VERSION> \
  && emerge -vq glibc \
  && emerge -vq binutils \ # not sure if $(eselect binutils) is necessary here
  && emerge -vq =gcc-<NEW GCC VERSION> \
  && fix_libtool_files.sh <OLD GCC VERSION> \
  && emerge -evq @system


I am not recommending this, though. I don't see any reason to do it unless there are binary compatibility problems or you are actually bootstrapping a new system with a new CHOST.

The LFS technical notes on bootstrapping the toolchain are here: http://www.linuxfromscratch.org/lfs/view/stable/chapter05/toolchaintechnotes.html

[EDIT] Also, I'm sure the fine folks who maintain the Gentoo toolchain do their best to make sure this isn't generally necessary.
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7470

PostPosted: Tue Oct 04, 2011 2:50 pm    Post subject: Reply with quote

It was also the stage1 procedure to build gcc/glibc.

Building only glibc without gcc would then gave you : faster compile as less things to compile vs possible stronger toolchain (at prize of a "might not be useful" rebuild)

I'm always ultra-safe with my toolchain (everything is kept mask until i decide to upgrade to another version that i kept in testing...), because i use distcc i try to maintain it under strict control. And i've seen many times user having trouble because a badly build toolchain result in random results, just browse the forum, you'll see how many users have been hit by that.

Also gcc is adapting itself to the system tools it found on your system : http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Fixed-Headers.html#Fixed-Headers
And this will remain as-is until glibc will be fully C99

A matter of choice, i've made mine as i don't really care about the compile time.
Back to top
View user's profile Send private message
voidzero
Bodhisattva
Bodhisattva


Joined: 21 Jul 2002
Posts: 265
Location: Grnn

PostPosted: Sun Apr 21, 2013 1:46 pm    Post subject: Reply with quote

Sorry if digging up this thread annoys anyone. The contents are still relevant and I have some questions that are in line with the discussion. Hopefully one of you can provide me with some clues.

In particular, with gcc 4.6.3, the above echo command on my machine yields:

Code:
 # echo "" | gcc -march=native -v -E - 2>&1 | grep cc1
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1 -E -quiet -v - -march=corei7-avx -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm -mavx -msse4.2 -msse4.1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=12288 -mtune=generic


And look at how this one differs:
Code:
# echo "" | gcc -march=native -mtune=corei7-avx -v -E - 2>&1 | grep cc1
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1 -E -quiet -v - -march=corei7-avx -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm -mavx -msse4.2 -msse4.1 -mtune=corei7-avx


My CPU (courtesy of OVH):
Code:
vendor_id   : GenuineIntel
cpu family   : 6
model      : 45
model name   : Intel(R) Xeon(R) CPU E5-1650 0 @ 3.20GHz
stepping   : 7
microcode   : 0x70d
cpu MHz      : 1200.000
cache size   : 12288 KB
physical id   : 0
siblings   : 12
core id      : 0
cpu cores   : 6
apicid      : 0
initial apicid   : 0
fpu      : yes
fpu_exception   : yes
cpuid level   : 13
wp      : yes
flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips   : 6399.82
clflush size   : 64
cache_alignment   : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:


What I'd like to know is, does -mtune=generic negatively impact the generated code? And the parameters for l1- and l2-cache-line-size, are those specific to my CPU?

There are some different outputs with these commands and I'd like to learn whether I should choose -march=native or -march=corei7-avx, and whether to change the -mtune=generic to -mtune=corei7-avx.

Thanks in advance 8)
_________________
Diplomacy is the art of letting the other party have things your way.
-- Daniele Vare
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6920

PostPosted: Sun Apr 21, 2013 5:55 pm    Post subject: Reply with quote

When you pass only -march=native, it's telling GCC to look at the CPU you're actually using and optimise for precisely that and nothing else. With -mtune you're telling GCC to compile for that CPU or a superset of it, so it can no longer make detailed assumptions like amount of cache it'll have available.

The -mtune=generic should be fine, all it's saying is to not do any CPU-specific performance workarounds; there's a separate -mtune=atom for example when native is in use, since that CPU has weak instruction-reordering.
Back to top
View user's profile Send private message
voidzero
Bodhisattva
Bodhisattva


Joined: 21 Jul 2002
Posts: 265
Location: Grnn

PostPosted: Fri Apr 26, 2013 6:33 am    Post subject: Reply with quote

Right, I understand. Thank you. :)
_________________
Diplomacy is the art of letting the other party have things your way.
-- Daniele Vare
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Unsupported Software All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum