make.conf parameters for core i7

[d2_racing]

Hi, if you use Gcc 4.3.3 then you should enable this feature
_________________
Sysadmin of Funtoo-Québec.org
Wiki
Signature
IRC on Freenode : #funtoo-quebec

[MaximeG]

Hi,

But in the case of an i7, isn't it already activated when using march=nathive ?

Thanks,
Maxime
_________________
Future is wide open.

[d2_racing]

I don't think so, because GCC 4.4.3 was release earlier then the CoreI7.

So you need to add it manually I think.
_________________
Sysadmin of Funtoo-Québec.org
Wiki
Signature
IRC on Freenode : #funtoo-quebec

[MartyMcFly]

Confirmed, this is working flawlessly in gcc-4.3.3-r1 (I've used http://www.gentoo.org/doc/en/gcc-upgrading.xml to upgrade gcc)

CHOST="i686-pc-linux-gnu"
CFLAGS="-O2 -pipe -march=native -msse4 -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"

I've updated the wiki entry accordingly.

[jasn]

I jot got my Clevo D900F with an i7-975 (3.33ghz) cpu and 6gb of DDR3 RAM, and I'm editing my post since I feel that the information I previously posted was inaccurate. As gringo points out in the next post in this thread, these are the CFLAGS I ended up using for my system;

[gringo]

[d2_racing]

In fact, but with core2 maybe you need to add them manually.
_________________
Sysadmin of Funtoo-Québec.org
Wiki
Signature
IRC on Freenode : #funtoo-quebec

[kernelOfTruth]

*subscribes*

mtune=barcelona is mentioned some times over at intel developer forums and also when comparing icc sse4.2x with gcc's sse4.2 capabilities and optimizations for core i7

no-one tried it ?


especially interesting was:

[Shining Arcanine]

[Gentoo4Work]

I've currently got a (funtoo) system up, running, and stable. GCC is 4.3.3r-something, gentoo-sources-2.6.33. Pulled from the core2 funtoo repos, rather than the amd64, for whatever difference that makes. The system was built with -march=core2 -O2 -pipes.

Hardware is 2x Xeon X5570's.

Could I simply boot sysrescueCD, tar my installation, copy it onto a few new partitions of the same disk, switch compiler options, emerge -uaDV world, and run benchmarks (assuming they all survive the upgrade)? I've been really curious about how much of a difference compilation options make for non-specific application, but don't want to risk breaking my working installation.

[d2_racing]

[depontius]

New CoreI7 user...

I'm just installing a new Thinkpad W510 with a CoreI7, so this thread popped up when I started thinking about revisiting "/etc/make.conf". To begin, I had:

[krinn]

Because you've misunderstood -j from emerge and the -j from make.conf

the -j from make.conf (the makeopts) is to feed your cpu while doing make: it will allow it to run as many gcc as you set
the -j from emerge is to feed your cpu while emerging: it will run many emerge as you allow it

(i will get back just on that just after that):

Ok so you've set -j9 in makeopts, allow 9 gcc runs
But it's how make works that prevent your cores to run at 100%

generally, this is what is happening: make need to be built 3 files, then with the 3 files it will be able to build a 4rd one, then again... upto end of compile.

So in this case, even you said, ok, use 9 gcc, make cannot do that and will only run 3 gcc, than 1...
because it need that file to be built and it need 3 files built before.
So you get
at 0s
file1: core1 building but need 3s to complete
file2: core2 building but need 5s to complete
file3: core3 building but need 10s to complete
file4: nothing for now, waiting 3 others to be built to run that one, will take 5s to build it
all others cores, wanking...

at 10s
file1: done
file2: done
file3: done
file4: core4 building for 5s
all others cores wanking...

So if you look at your stats, you'll see real poor stats
core1: was working full only 3s, 20% (because 3s out of 15s working)
core2: was working full only 5s 33%
core3: was working full only 10s 66%
core4: was doing nothing for 10s and working full for 5s 33%
Hu, that's ugly stats
As you see it just mean you've find a make that cannot really feed your cores with enough "real" jobs to put them down

now the emerge -j4 (--jobs) options, this time you allow emerge to run multiple emerge jobs.
this mean running 4 emerge at once, so you need to feed emerge with that, best way would be emerge system or world but let's take a sample
emerge -j4 package1 package2 package3
again: asking -j4 but only 3 package, if no dependency is need, only 3 emerge will run, see how it's hard to feed the beast?

Ok, i'm not sure for that next one if emerge take the makeopts as global or per package settings
if global : emerge -j4 with makeopts=9 = 9 = upto 9 gcc
if per emerge: emerge -j4 with makeopts=9 = 4*9 = upto 36 gcc run (this is what happen if you do emerge package1 & emerge package2 & emerge package3)

So, if you really need to feed your cores, use emerge -j8 will help much than makeopts=-j8, and using them both, you'll have a setup to really see the core7 performance.
the -j8 for emerge is to be set in EMERGE_DEFAULT_OPTS="-j8"
the -j8 for make is to be set in MAKEOPTS="j8"

You should try emerge prll
prll is a tool that will do the --jobs function but for any program, let's say you have to convert all *.mp3 to ogg with an mp3_2_ogg tools, prll will feed your cores with your number of cores jobs (ie: for you, running upto 8 mp3_2_ogg tools).
A nice tools for multi-cores users.

(ps: btw: using -march=core2 -mtune=generic => allow gcc to use any core2 code but limit the usage of that set to only build code that could run on any x86_64 computers. So you've just limit your code optimisation. Set -march=core2 -mtune=core2)

[depontius]

Thanks for the tips, I see your point. When my extra DRAM gets here, I'm thinking of mounting tmpfs over /var/tmp/portage with a decent max size. Then after emerge has unpacked the source, the whole thing runs in RAM. I suspect that will do more for performance than anything with "-j", though I would also expect it to make "-j" work better.

I was unaware that "-j" could be used as an option to emerge - I presume when package2 directly requires package1, things still turn out to be serialized?

As for the CFLAGS, why would the "safe CFLAGS" page have said to use "-mtune=generic"? Isn't "-march=core2" equivalent to "-mcpu=core2 -mtune=core2"? I also saw stuff up-thread here about having some other flags like "-sss3e" and such. Any comment on those? Is gcc-4.5 supposed to directly support CoreI7?
_________________
.sigs waste space and bandwidth

[krinn]

[kklatt]

When reading the posts on I7 and portage, I saw mention of using the AMD64 base rather than the x86 -- Did I misunderstand?

-- Update : Went ahead and installed the AMD64 stage 3, working fine.. I did note the emerge -j option, did not affect the system build and updates, as the packages being built depends limited the builds to 2. Using a small 32G SSHD as the system drive, machine has 12G of ram. Neglected to think how large swap should be at 3x memory, not a practical issue for a while. Building GNOME, passed the emerge with j-6 -- first died on building the library icu, rebuild icu by itself and worked finem same with libatasmart. /var/tmp is set to 4G, did not see a space problem (cause for review later.) Building 4 packages (j-4) , seems to work the best, unsure as to why. All in all, working well --

[BlackMajick64]

Just wanted to post my experience with Corei7 on Gentoo x86_64...... the following is what I have found after 3 months of off and on testing:


... march=core2, march=nocona, march=native are now completely obsolete with GCC 4.6.x using Corei7.

I have recompiled with emerge -eDv world (20x loop of this) on several occasions using GCC 4.6.0 and 4.6.1 with the following:

CFLAGS="-O3 -march=corei7 -mtune=corei7 -pipe -funsafe-loop-optimizations -funsafe-math-optimizations -msse4.2"

works like majick - if you dont' have GCC 4.6.x yet give it a whirl, it doesn't break anything for me as of yet, and as I've said I always recompile @world just to be safe and in my case it's 900+ packages. i then prelink everything and it works as expected.

also consider upping your MAKEOPTS.... not sure why the "threads +1" is still recommended, I use MAKEOPTS=-j100 all the time with 24GB of RAM. if you can afford to tie up your machine CPU and memory wise for awhile to do a recompile do yourself a favor and try it out. it does not slow down the compiles at all, but makes them fly. the corei7 will rip right through it , better than Xeons on most occasions I notice.

Try putting it to 30-40 if you have less RAM, the corei7 will fly. Don't be afraid to try upping the MAKEOPTS to a ridiculous number, you can ALWAYS go back. A couple of programs fail, like Boost regex for example. This is simply fixed by reducing the MAKEOPTS (in my case with 24GB going down to -j60 works like a charm).

However with using GCC 4.6.x a word of warning (this is already clear in the portage messages when you emerge) - don't use the LTO it breaks a ton of stuff right now for me. Do NOT use -mavx if you do not have an Intel Sandy Bridge that has AVX extensions - after you emerge zlib it will break everything, including your compiler , with no way that I have been able to see to fix it. format/re-install for me has been necessary and I will no make that mistake again.
_________________
Asus Rampage III Extreme
24GB Samsung DDR3-1600MHz
I7 990x Extreme Edition Hexcore w/HT o/c 4.2Ghz
5x Intel 80GB SSD/RAID0
4x 7.2K 2TB/RAID5
2x Geforce GTS 250/SLI
50Mb/s bizclass cable
2.6.39-r3
MAKEOPTS="-j100"

[myceliv]

Quick side note: a good way to deal with packages that want MAKEOPTS="-j1" or whatever... say dev-libs/icu ... is

[kosik]

[kosik]